Tag Archives: open banking

WSO2 Open Banking: Reaching Many Milestones in August 2019

WSO2 Open Banking completed its second anniversary on the 3rd of August. Since its inception, WSO2 Open Banking has set out to do three things: 1) Provide technical efficiency for banks who need to comply with PSD2 and Open Banking, 2) Stay relevant in the wake of the constant changes in the open banking world, and 3) Contribute to the global open banking movement. The latest release of WSO2 Open Banking ticks all three check boxes. This blog discusses each of the above mentioned points and how WSO2 Open Banking helps in more detail.

Support for Global Open Banking Standards

Open Banking API standards have revolutionized how effective API programs can be built for open banking. Open Banking UK API Standard and the NEXTGEN PSD2 API Standard (created by the Berlin Group) are two of the most commonly used standards. The Open Banking UK API standard is globally recognized, with countries like Australia and even some parts of Asia using it as the starting point to build their own specifications.

These API standards release a new version about every 6-8 months. A key priority of WSO2 Open Banking’s roadmap is to stay in line with these API Standards. Why? To help banks using WSO2 Open Banking to easily migrate to the updated versions, without having to spend cycles on implementing version updates themselves. But the benefit is not just for existing customers. Any bank who is looking at using WSO2 has the assurance that the solution’s technical capabilities are in sync with the regulatory demands.

Here are some of the improvements that have come about with this release:

  • Support for the UK v3.1.1 read-write API standard which mandates how Accounts, Payments, and Confirmation of Funds requests are handled.
  • Support for Dynamic Client Registration (DCR) v3.2 – To mandate the mechanism where a Third Party Provider (TPP) client should be able to register with the Account Servicing Payment Service Provider (ASPSP) using DCR.
  • Authorization endpoint support for Berlin API v1.3 NEXTGEN PSD2 API.
  • Transaction Risk Analysis (TRA) to help identify the right conditions to implement strong customer authentication (SCA.)

Meeting the September Deadline for Regulatory Technical Standards (RTS)

By September 14 of this year, all banks in Europe and the UK are expected to have several security measures in place to ensure that customers get to enjoy the benefits of open banking with no security compromises. Having basic identity and access management capabilities do not make the cut for PSD2 compliance and Open Banking. This is one of the key reasons why WSO2 Open Banking has always focused heavily on augmented security capabilities such as strong customer authentication and comprehensive consent management.

As such, this release supports:

  • Electronic Identification, Authentication, and Trust Services (eIDAS) to ensure secure electronic transactions.
  • SCA for electronic payment transactions.
  • Rule-based fraud detection and dashboards for monitoring fraudulent transactions.

Giving Developers the Experiences They Deserve

Much of the interaction between WSO2 Open Banking and a bank’s technical infrastructure is facilitated by the bank’s development team. The following feature implementations will allow a bank’s development team with greater flexibility and creativity when working with WSO2 Open Banking. Some of the developments include:

  • Externally deployable authentication endpoint to allow banks to deploy the authentication endpoint in a separate environment.
  • Extendable consent retrieval and consent persist steps to help banks to conduct their own customizations to the flow seamlessly and elimination duplicated efforts.
  • Transaction Risk Analysis (TRA) implementation has been moved to Open Banking Business Intelligence to help developers easily track and monitor TRA patterns.

More information on the technical capabilities can be found in this blog. If you are interested in getting an even deeper understanding of these features, do register for our webinar.

If you are interested in getting WSO2 involved with your open banking or PSD2 compliance projects, do reach out via our web page. We would love to be a part of your journey.

WSO2 Open Banking 1.4: Support for Global Open Banking Standards

WSO2 Open Banking supports global banks with their PSD2 compliance and open banking journeys. The latest release of WSO2 Open Banking 1.4 meets the technical and regulatory requirements for two global Open Banking API Standards – Open Banking UK API v3.1.1 and NEXTGEN Second Payment Services Directive (PSD2) API v1.3 standards.

This release also focuses on helping European and UK banks meet the requirements of the Regulatory Technical Standards (RTS). The RTS requires banks to have several technical features and standards applied to their Open Banking APIs including Transaction Risk Analysis, eIDAS support, and data reporting among others.

What Can Open Banking Developers and Architects Expect From WSO2 Open Banking 1.4?

Support for Open Banking UK API v3.1.1

Accounts, Payments, and Confirmation of Funds

  • Provide support for the UK v3.1.1 read-write API standard which mandates how Accounts, Payments, and Confirmation of Funds requests are handled.

Dynamic Client Registration DCR v3.2

  • This API mandates the mechanism where a Third Party Provider (TPP) client should be able to register with the Account Servicing Payment Service Provider (ASPSP) using DCR.

Support for Berlin API v1.3

Accounts, Payments, Confirmation of Funds

  • Provide support for the Berlin API v1.3 NEXTGEN PSD2 API standard which mandates how Accounts, Payments, and Confirmation of Funds requests are handled.

Authorization endpoint support

  • Authorization endpoints satisfying the NEXTGEN PSD2 API requirements. This API supports explicit authorization sub-resources and payment cancellation authorization.

Other Features

Transaction Risk Analysis (TRA)

  • TRA for both UK and Berlin specifications. This helps Improve the user experience of exempting strong customer authentication.

eIDAS Support – RTS

Provides support for:

  • eiDAS Qualified website authentication certificate (QWAC) validation in the transport layer.
  • eiDAS Qualified Electronic Seal (QSeal) certificate validation for message signature.

Management Information Reporting for Open Banking UK API standard

  • Data reporting functionality based on UK specification. This data is used to generate reports required by the standard. These reports cover various specification mandated authentication and API statistics.

Ability to restrict PS256 as the signing algorithm for incoming requests which contain signed Json Web Tokens (JWTs) as required by the UK specification.

Fraud Detection Requirements based on RTS. This includes Rule-Based Fraud Detection and dashboards to monitor fraudulent transactions.

An Enhanced User Experience for Open Banking Developers

WSO2 Open Banking 1.4 improves developer interaction with the various technical and regulatory components of the solution through the following:

Swagger based request payload validations – Account and Payment

  • The payload validation is moved to swagger based validations instead of manual validations. This helps increase the effectiveness and completeness of the validations.

Re-architecture of authentication endpoint

Re-architecture of the authentication endpoint to cater to the following requirements:

  • Externally deployable authentication endpoint. This is required when banks want to deploy the authentication endpoint in a separate environment.
  • Extendable consent retrieval and consent persist steps.
    Enables banks to conduct their own customizations to the flow seamlessly without having the need to re-write parts of the authentication flow.

Transaction Risk Analysis (TRA) implementation moved to Open Banking Business Intelligence

  • The TRA implementation which used to function as java based classes, is moved to siddhi (OBBI) as siddhi apps. This increases the efficiency of the TRA component.

OBBI is built with API Analytics incorporated so that OBBI users don’t have to deploy a separate APIM analytics node

Ability to extend key manager extension to add authentication steps based on Strong Customer Authentication (SCA) requirements

  • Different customers use different authentication steps in the authentication process. This feature reduces the effort taken to add an authentication step.

Introducing new REST APIs for operations in WSO2 Open Banking

  • API endpoint to retrieve Third Party Provider (TPP) information.
  • API to retrieve data to be displayed on a consent page.
  • API to persist consent data from a consent page.

In addition to these developments, the solution is now compliant with the OBIE Security Conformance Suite v3.1.0 and Functional Conformance Suite v1.1.17 versions.

Why Choose WSO2 Open Banking?

WSO2 Open Banking is purpose-built to align technology infrastructure and regulatory needs with domain expertise to fully satisfy technology requirements for open banking. The solution roadmap focuses on updates that keeps the solution on par with global Open Banking API standards. This helps banks using WSO2 Open Banking to easily migrate to these newer versions, without having to spend cycles on implementing version updates themselves.

Our webinar about the latest release will take you through an in-depth discussion on how WSO2 Open Banking 1.4 can expedite your compliance journeys and prepare you for the RTS deadline.

Another key advantage WSO2 Open Banking is its flexible architecture that meets technology use cases extending beyond open banking. Built on top of a unified integration platform, it helps banks extend open banking initiatives to any API-first digital initiative.

For more information on how WSO2 Open Banking can help your open banking journey, please visit our landing page.

Looking for more helpful resources? Here they are:

Documentation for WSO2 Open Banking

A Deep Dive of Transaction Risk Analysis for Open Banking and PSD2

Successful Third Party On-boarding for Open Banking UK

Fraud Detection: Making Open Banking a Safer Place

Strong Customer Authentication and Dynamic Linking for PSD2

Australia Passes Consumer Data Right Legislation. It’s Go Time for Open Banking!

Photo credits: Catarina Sousa via Pexels

After much anticipation, the Consumer Data Right Legislation is finally passed! Just after a month since the original open banking deadline for the Big 4, the real race begins. It’s time for banks to lay out their open banking playbooks and start implementing open APIs.

A Quick Overview of the Timelines

Even before you consider the technical aspects of open banking, you should understand the regulation. Our article answers some common questions around open banking in Australia. A summary of the approaching deadlines is included below:

  • February 2020: Credit and debit card, mortgage, deposit, and transaction data by the Big 4 banks
  • July 2020: Account data for all banks aside of the Big 4
  • February 2021 for mortgage data: Account data for all banks aside of the Big 4
  • July 2021 for all other products

How to Get Started

With less than a year to go, banks have a lot of prep work to do. Here are a few simple steps to kick start your technology implementation for open banking:

Create open banking evangelists: Even if it is just 3 people, it is important that there is a part of your organization that lives and breathes open banking. That way, they align every aspect of the business – customer value, profitability, and even vision towards a pro open banking model.

Budget for efficiency: Open banking doesn’t have to cut through a hole in your annual budget. An efficient open banking implementation is one that will not cost you a ton of money. And in order to budget for efficiency, always think about what you can re-use and re-purpose. As banks, most of the technology required for open banking should already be within reach. What matters is how you adapt it to fit open banking specific needs. Our article has more details.

Evaluate existing technology: Open banking does not require you to reinvent the wheel. You would already have banking APIs and data security mechanisms in place, and most of it can be modernized to fit open banking requirements. Our white paper covers this in detail. You just need to identify the gaps. And pay close attention to security. Features like customer authentication and consent management are crucial to the success of open banking.

Fill out the missing pieces: This is where you get creative. Once you know what is missing, always look at working with technology that is easy to integrate with current systems (so it doesn’t take much time), meets open banking specific customizations (so your teams don’t have to spend cycles implementing them), and finally invest in technology that gives you the flexibility to scale as you go. That way, you lower the risk in the technology investments that you make.

Test like your life depends on it: Once your open API environment is set up, make sure to test all of the functionalities are meeting requirements. When testing, think like a data recipient and envision the experience you want them to have. Remember, the better your API portal, the more data recipients you attract and the better you serve your customers.

We are excited to participate in the open banking journey in Australia and we are keen to share our experiences with banks like Société Générale with you. If you are just starting your open banking implementation or have made progress but need more technical or regulatory guidance, do get in touch with us.

Everything you need to know about WSO2 Open Banking is here.

The Basics of Open Banking

Open banking has grown overnight. It started with the PSD2 regulation for Europe in 2018. Open banking is now adopted in Australia, several parts of Asia, Latin America, and many other regions.

Here are a few facts to understand what open banking is and why you should consider building a strategy around it.

What is Open Banking and Why Was It Created?

Open banking requires all financial institutions (deposit taking institutions) to open up customer and/or payment data to third party providers. Open banking breaks up the monopolies of financial services and allows more players to enter the market. This increases competition and results in better products and services for customers.

As time went on, non regulated regions started to accept that open banking was the best way to become more digitally agile. Therefore, they started taking measures to open up their APIs. Regions like Mexico are looking at open banking for larger financial inclusion agendas.

How Does Open Banking Work?

The “opening up” of this data is done via Application Programming Interfaces (APIs). APIs, which are essentially an integral part of any technology infrastructure, provide a secure and effective way to expose this data. In the past, banks have used screen scraping to expose data. This comes with a compromise on security with a high chance for fraudulent transactions.

How is Data Protected in Open Banking?

Security is of utmost importance in open banking. While security at an API management level is essential, banks must take extra steps to ensure that data does not fall into the wrong hands. Mechanisms like Strong Customer Authentication (SCA) and Consent Management are vital. SCA ensures that a two step authentication mechanism is followed, but without hindrance to user experience.

Consent management puts the user in control of who they share their data with. When you implement identity and access management for open banking, these two elements should be a top priority. It also helps to have fraud detection mechanisms in place, as a way of identifying fraudulent transactions.

Are There Technology Standards to Meet?

Since the APIs used for open banking need to follow certain protocols and adhere to specific requirements, there are a few open banking API standards available. Open Banking UK API Standard, the NEXTGEN PSD2 API Standard (created by the Berlin Group), and the STET API specification are three of the most commonly used standards.

How Do You Integrate an Open Banking Architecture with a Legacy System?

One of the biggest challenges banks face is bringing together what seems to be two different worlds — open API architectures and legacy systems. In reality, it doesn’t have to be so difficult. The first thing to do is to add an integration layer which will mediate between the legacy system and Open APIs. This allows you to expose the required services to the open banking solution, which will in turn expose them as APIs with the required security measures in place. More details are available in this white paper.

Why an Open Banking Vision is Important

The availability of data and various methods to compare and contrast services create high expectations for consumers.This means banks need to go the distance — being a supporter of a person’s financial ecosystem is not enough. They need to think about improving consumer lifestyles too.

Open banking is the best way to start this journey. The openness it creates gives way to a tremendous amount of data. This data helps you understand how your consumers, eat, shop, travel, and more. With more players in the financial services ecosystem, banks should aim for collaboration over competition.

These collaborations can go a long way in delivering superior products and services to customers, and helping your bank identify as a true contributor to consumer well being.

In conclusion, open banking is here to stay. So regardless of what the regulatory status is, banks need to be proactive about open banking and make it a boardroom topic. The sooner you start, the better placed you are when it reaches your region.

What’s New in WSO2 Open Banking v1.3.0

WSO2 Open Banking caters to global open banking requirements. The latest release, version 1.3, focuses on helping banks open up their APIs for external testing. This was brought about by the March 2019 deadline for PSD2 and Open Banking, which requires all banks operating in Europe and the UK to have a sandbox environment ready to open up their APIs securely to third-party providers (TPPs). This blog discusses the new release’s features, improvements, and changes.

How can banks have their open banking setups ready for external testing?

From a UK standpoint, the Open Banking Implementation Entity (OBIE) mandates that the UK Open Banking API specification v3.1 should be used for the March deadline. If you look at the revised roadmap, it explains what is required for each deadline based on the bank type, CMA9 or non-CMA9. The API Release Management Policy explains the API specifications that the bank needs to support based on the time it is published.

We considered the following UK standards for the new release:

Europe follows the Berlin Group NextGenPSD2 and STET specifications. However, the region does not have mandated requirements for the March deadline. The new release also includes support for the Berlin Group NextGenPSD2 specification v1.1 and the STET specification v1.4.

In addition, the release includes enhancements to security, user experience, transaction risk analysis, and fraud detection considering future requirements beyond the March deadline.

The complete release notes can be found here.

Packaging of WSO2 Open Banking

WSO2 Open Banking comes with three product packs:

  1. wso2-obam-1.3.0
  2. wso2-obkm-1.3.0
  3. wos2-obbi-13.0

A user with a WSO2 subscription can download the WSO2 Open Banking solution via WSO2 Update Manager (WUM). As WSO2 Open Banking is closed source, it is not publicly available to download.

The wso2-obam pack contains API management-related components including the key generation, consent management, and authentication (identity and access management) components.

The new v1.3.0 release introduces wso2-obbi – WSO2 Open Banking Business Intelligence. The business intelligence component should be purchased to utilize transaction risk analysis, fraud detection, business intelligence, monitoring, and reporting capabilities.

The wso2ob-am-analytics and wso2ob-ei components have been removed from the open banking solution as the wso2-am-analytics and wso2-ei products offer the same functionality. So hereafter WSO2 Open Banking will not maintain or improve the features of those components.

A Standard Open Banking Deployment

If we consider the open banking requirements for different banks and regions, the main requirements are covered in the Open Banking API Manager and Open Banking Key Manager components. Our standard deployment contains wso2-obam and wso2-obkm, as shown in the below image.

The Open Banking API Manager component provides API management capabilities. It needs to connect with the internal banking systems to expose the required data and services to external third parties. The Open Banking Key Manager component provides API security, strong customer authentication, consent management, and user management capabilities.

How to Extend the Standard Deployment

With Analytics

A bank may want to see how their APIs are performing, provide analytics to third parties to see how their applications are performing and make decisions based on those to improve the whole open banking ecosystems. To do this they need to download wso2-am-analytics and integrate with the standard deployment as shown below.

With Integrator and Workflows

When exposing internal bank data and services via APIs to third parties, open banking solutions need to integrate with the internal banking system. If that internal bank system has its own API, we can directly map those with the external APIs. However, you may need to add an additional layer that can transform different message formats and protocols. In such cases, banks can integrate the WSO2 EI Integrator Profile.

Some banks may want to have business workflows for certain functionality. For example, when a third party signs up with the open banking solution, the bank wants to take them through the approval process where someone goes through all the third party information and provides the approval to access the exposed APIs. Another use case involves the bank wanting to introduce the approval process when a third party wants to access a production API after testing in the sandbox APIs. In that kind of situation where a bank wants to introduce human interaction, it can be achieved by introducing the WSO2 EI Business Process Profile to the standard deployment.

Both these scenarios (integrator and business process profiles) are shown in the image below.

With Business Intelligence

Apart from the basic compliance requirements that are required for the March deadline, there are more requirements mentioned in the Regulatory Technical Standards (RTS) and guidelines published by the European Bank Authority (EBA). Transaction risk analysis (TRA) and fraud detection gets the highest priority among those requirements because once the banks open up their APIs to external parties, there’s a high chance for fraud to happen.

That’s why WSO2 Open Banking now provides a new component – Open Banking Business Intelligence (OBBI), which analyzes the transaction risk and identifies fraud situations. The OBBI component can be integrated with the standard deployment as shown below. If any bank has its own TRA and fraud detection systems, that can also easily be integrated with the standard deployment.

This OBBI component is built on top of the Siddhi engine, so this component can also provide business insights, and reporting and monitoring capabilities. If a bank wants to build their own dashboard, that is also supported through this component.

WSO2 Open Banking is OBIE Security Conformance Certified

The OBIE has implemented a test suite to help Account Servicing Payment Service Providers (ASPSPs), TPPs and solution providers to check that they have implemented each part of the OBIE standard correctly, i.e. Read/Write APIs, Security Profile, Operational Guidelines, and Customer Experience Guidelines. When the implementers use these tools to self-attest, then OBIE validates and publishes the conformance certificate. These certificates can be used by implementers as evidence to all parties including regulators that they have followed the standard correctly.

We are pleased to announce that WSO2 Open Banking OBIE Security Profile Conformance Certified. You can see that WSO2 is listed as an OBIE Security Profile Compliant solution here.

If you wish to run the OBIE security profile conformance suite against the WSO2 Open Banking solution, this document provides the instructions for your reference.

WSO2 Open Banking Documentation

Another great improvement that came with WSO2 Open Banking v1.3.0 is the availability of public documentation. Here are some of the important links to WSO2 Open Banking documentation.

If You Missed the March Deadline Without a Sandbox Environment Ready

All banks in Europe and the UK were required to have their open banking setups ready for external testing by March 2019. If your bank couldn’t meet that deadline yet, or is still struggling to select the required open banking platform, WSO2 can help you. Here are some useful resources:

Our Next Release to Meet the September Deadline

Our next target is to help banks achieve the regulatory deadlines that fall in September. This includes providing a production system available for third parties to go live with their third-party applications.

We are planning another release before September to ensure banks have time to upgrade their solution on time. That release will contain the required implementations of the UK v3.1.1 Specification for banks in the UK and Berlin Group NextGenPSD2 v1.3 Specification for banks in Europe.

Apart from that, we are working towards implementing the Australia CDR Specificationtoo.

Conclusion

WSO2 Open Banking is purpose-built for global open banking. It is built to align banking and regulatory needs with technology infrastructure and domain expertise to fully satisfy the technology requirements for PSD2 and Open Banking. If you missed the March 2019 deadline to open up APIs, we can help. The solution roadmap focuses on several enhancements to the solution especially those in line with meeting the September 2019 deadline for the RTS. If you’re exploring open banking or you’re already knee deep in a PSD2 compliance project and require a technology partnership, drop us a note at openbankingdemo@wso2.com.

Why We Make Our Product Roadmaps Public

“Can you please share your roadmap?”

“What are your plans to engineer feature xxx?”

“Great product, but does your vision match ours?”

We get these questions all the time, from customers, partners, and analysts.

As the leading open source API integration company, it seemed antithetical to be open and transparent about our code, financials, and priorities, but not about our actual product roadmaps.

So we’ve now opened-up our product and solution visions and roadmaps for each of our integration-related products, all part of our Integration Agile platform:

Why would we do this?

There are a number of reasons we chose to take this bold step – a step that most high-tech companies shun as competitively risky, and thus guard their plans with absurd paranoia.

  • Public roadmaps are consistent with our open source community
  • We trust our community to work with us, and they can only do so if they know our plans. That way they are always involved in the technology and will be able to best deliver meaningful new features, contributions, and roadmap suggestions.

  • Public roadmaps signal our transparency
  • Transparency is key to building trust between partners. A public roadmap helps committers, partners and customers to know we’re pulling no punches with our direction. It’s also consistent with our no-lock-in approach… and that means there’s no lock-in to our roadmap either. With a transparent set of roadmaps, our technology partners know what to expect… and have a proactive vehicle to comment on the direction.

  • Public roadmaps are good for our customers’ trust
  • When our customers buy-in to our integration platform, they’re putting technology direction on the line. They want to know if we’ll be evolving in the direction they want. For them, it’s all about mitigating long-term technology risk. This way, we’re “opening the kimono” and boldly stating direction.

  • Public roadmaps show our pride, confidence, and vision
  • WSO2’s technology has been evolving for over 13 years. Over 350 engineers currently work on technologies like API management, identity management, ESBs, enterprise integration, and related integration architectures. This is one way of showing-off our vision and capabilities.

  • Public roadmaps are good for business
  • In sales situations, customers often ask pointed questions about specific (missing) features. And the usual answer “Yup, we’re working on supporting it” is always received with skepticism. Our public roadmaps put our money where our mouth is… either it’s on the roadmap, or it’s not. Or, we work with our partners to change the roadmap… for everyone else to see.

Next, what’s on our Roadmap roadmap?

This is the first of many more steps we’ll be taking toward increased openness and transparency. But the other critical component is your feedback. So if you have thoughts about our roadmap- positive or negative – there are many avenues you can use, including our Contact Us button – and include your feedback.

Evolution of Nations Trust Bank’s Open Banking Story

Established in 1999, Nations Trust Bank (NTB) is one of the largest private banks in Sri Lanka with branches located throughout the island. They’re not new to introducing novel concepts and innovation. NTB was the first bank in the country to introduce 365-day banking and they’ve recently pioneered open banking in Sri Lanka. One of their innovations is FriMi – which also happens to be Sri Lanka’s first digital bank, mobile wallet, and payment system that is fast gaining in popularity. In fact, NTB was named one of the top 30 local business establishments and FriMi was named as one of the country’s top 30 financial institutions by the Asian Banker magazine.

Pioneers in Open Banking

Unlike other parts of the world, NTB was not driven by regulatory needs to introduce open banking. They wanted to align their strategies to cater to changing customer expectations and enable collaboration and data sharing within financial services providers in the country. By doing so, NTB was seeking to create new business opportunities and partnerships with startups. Since NTB offers a vast range of services for their customers, their main challenge was ensuring that no service disrupts the functioning of another service and inconveniences customers in the process.

Nisala Kodippili, the chief information officer at NTB, explains that one of the main issues they faced were the many integrations done at different times and at different levels. NTB’s ATMs and mobile and internet banking services used different APIs. This created a scenario where there was a discrepancy in the account balance displayed when customers accessed their accounts via ATMs compared to when they viewed their accounts using mobile banking! NTB managed to solve this problem by developing a method where they use a single API and to avoid these issues faced by customers. Ironically this set the stage for a bigger problem. Whenever there was an issue with one API, the entire stack is disrupted making this a single point of failure for everything. When this happens, the only way to bring in a new service is to build multiple APIs from multiple systems and identity management at multiple levels is not an easy task.

The Right Technology

To manage the different identities and APIs better, NTB turned to WSO2 Open Banking. Leveraging WSO2’s API management, security, and integration capabilities, WSO2 Open Banking provides the technology for open APIs, third party services, and digital transformation of financial services. It is built on architecture that can scale to deliver compliance for different deployment sizes. “Maintenance is simple, if there are any changes you have to go through the API Manager and do the modifications,” says Nisala. NTB’s new architecture is created in such a way where only one identity is needed for various applications, enabling them to collaborate all identities onto one platform.

Thanks to their new solution, NTB is now able to integrate easily with any new third party within a week. Nisala says that he and his team were astounded by the improvements, “It’s simply a matter of somebody consuming our API and even I didn’t expect the other service providers to follow us. But I’m proud to say that service providers and other third-party integrators who are working together are willing to move to the standard level. They are consuming our APIs very quickly.

Customer Satisfaction is Key

Customers who want to make any changes to their account now only need to make this change once and it reflects on all other services. Security has also improved and NTB has extensive monitoring capabilities where they can control the level of APIs consumed by a single party. “It’s very easy, even at the merchant level we can control the API consume levels,” Nisala explains. Using single sign-on for all applications has helped them to eradicate the issue of duplication of identity. WSO2 Identity Server manages this for NTB, regardless of what the third party application or any other application brings in. This has improved the user experience tremendously.

Nisala says that NTB has unlocked their true potential by venturing into open banking and their new architecture which is free from single point failure has helped them reach new heights. “WSO2 has enabled us to build, scale, and secure sophisticated integration solutions to achieve our digital agility,” says Nisala.

To learn more about NTB’s open banking journey, watch Nisala’s presentation.

Curious to learn more about WSO2 Open Banking? Everything you need to know is here.

Open Banking Implementations in Europe and Africa: The Story of Société Générale (So Far)

Investment and retail bank Société Générale has its headquarters in Paris, France plus 45 branches in 36 countries, representing over 18 million customers globally. Retail banking services support 3 business lines in the regions of Europe, Africa and the Mediterranean, and Russia. Their 2020 strategic plan is simply named “Transform to Grow.” Open is the keyword here. “We want an open approach to develop offers and client satisfaction,” says Jean-Louis Rocchisani, enterprise architect at Société Générale.

The Transformative Powers of Open Banking

Open banking plays a crucial role in Société Générale’s transformative approach to business growth. Their open banking journey started in 2015, having recognized the opportunities it presents for improving the time-to-market and reforming their business model. Their open banking efforts have not passed by unnoticed. Recently, Société Générale was selected as the most advanced company out of 44 listed companies in the French market. After investing in the needed architecture, Société Générale now looking to extend towards the bank as a platform model.

Société Générale also sees the the transformative power of technology and APIs in its future. “We’re currently in the proprietary model, but we see the opportunities to increase our distribution power by creating a smooth digital end-to-end process,” says Jean-Louis. “We’re also looking to monetize our services and most importantly, create interactions between service producers and customers – which is also quite hard to launch. But this is possible because we have APIs as a product.”

Société Générale is guided by open banking drivers in the many parts of the world that they operate in. These include PSD2 compliance and beyond in Europe, modernizing B2B2C models, and enhancing digital banking services (as is the case in Africa). Community plays a central role in Société Générale’s open banking efforts, as markets are different and evolving across countries, and working with local communities of financial service providers is essential.

Jean-Louis presenting at WSO2Con EU

How Société Générale Came Across WSO2 Open Banking

Société Générale and WSO2 have a strategic partnership that dates back to 2015, ever since the first successful implementation. Their first success story and the fact that WSO2 is open source were major deciding factors for Société Générale. SOSMART is the acronym for Société Générale’s architecture principles which are sustainable, open, modular and real-time, and API first. They were looking for a technology partner who would accompany them for the entirety of their open banking journey. WSO2 Open Banking provides the technology for open APIs, secure integration with banks and third parties, and integration analytics capabilities. “WSO2 has innovative products, efficient people, and a shared vision with us,” explains Jean-Louis.

Use Cases From Africa and Europe

Germany: This was the first use case implemented by Société Générale and is centered on equipment finance, financing for big customers through vendors. This project began by implementing a B2B2C platform using WSO2 Open Banking, using the support from local vendors. This platform is now extended to include international vendors as well, using a federated model rather than a shared one to improve its efficiency.

Czech Republic: A large bank in the Czech Republic needed to leverage PSD2 towards open APIs, using WSO2 Open Banking. The bank is now working with fintech developers and partners in the country, using the API platform which was launched. This bank is looking to close the gap between iteration and deployment and they’re satisfied with their progress so far.

Africa: Société Générale works on innovations to digital and mobile banking rather than regulatory compliance in their African business operations. They currently have 12 banks in Africa, all of whom are different despite sharing the same core banking system and is therefore difficult to scale use cases from one country to another. An API layer has reduced the time to market, and the next stage is to open this platform to fintechs and other service providers in the ecosystem.

France: Société Générale’s French overseas territories banks have to achieve PSD2 compliance. In spite of the tight deadline, Société Générale believes this can be achieved on time and are using WSO2 Open Banking to speed up the implementation.

What’s Next?

With experience gained from a string of successes, Société Générale has more exciting projects lined up together with WSO2 Open Banking. For Jean-Louis, technology is an enabler (and not a constraint) and he says, “We believe in an interoperable world, where technology opens up possibilities leading to more success stories.”

Listen to Jean-Louis’s complete presentation in this video.

WSO2 Open Banking helps you achieve regulatory compliance in Europe and Australia, with successful use cases from around the world. Learn all about its capabilities here.

Ask an Expert: Catching up with Seshika Fernando

Women in engineering are unicorns (almost) and that’s probably why #Ilooklikeanengineer became a thing. But WSO2, with a 30% female representation, tells you a different story. Plus, we consider everyone at WSO2 a handpicked lot. So is Seshika Fernando. She’s a Chevening scholar, a speaker at conferences around the world, backed by both finance (London School of Economics) and computer science. Outside her workspace she’d be playing basketball as if it were rugby or making sure her son Ezra is getting enough sleep.

We caught up with Seshika recently to speak to her about her transition from the WSO2 analytics team to financial solutions, why open banking is taking over the world, and why she encourages more girls to join the IT industry.

1. How have your experiences at WSO2 been so far?

It’s been great! I was originally involved in data analytics while in the Research team. Now I manage the financial solutions initiative at WSO2 where I am able to capitalize on my background in Finance and create specialized solutions on top of WSO2 products, catered towards the specific business requirements of the financial industry.

I’ve had great experiences at WSO2. From being able to speak at atleast half a dozen international conferences a year, to interacting with some of the largest brands in the world, to playing basketball. WSO2 has been a great place to work irrespective of the team I belonged to.

2. How did the idea for building an open banking solution come about?

Open banking is taking over the banking world – not only in Europe but globally. And our open banking solution, built on top of the battle hardened WSO2 products, is proving to be very useful in all these markets.”

WSO2 gave me a challenge – “create solutions for the Financial Services industry using WSO2 products.” With a background in Computer Science as well as Finance, I took this up with open arms. At the time we started this initiative, PSD2 was taking over every conversation in the European banking sector.

With many of our existing customers coming to us with the PSD2 requirement, we forged ahead and created WSO2 Open Banking. Now in retrospect, this was the best decision we made. Open banking is taking over the banking world – not only in Europe but globally. And our open banking solution, built on top of the battle hardened WSO2 products, is proving to be very useful in all these markets.

3. This leads us to believe that the market for PSD2 solutions is open to many forms of competition. How did you formulate a technical and sales and marketing strategy to ensure WSO2 stands out?

Yes, there was stiff competition when we started. However, thanks to the vast capabilities of WSO2 products, surviving and thriving within this landscape have been easy.

There was stiff competition when we started. However, thanks to the vast capabilities of WSO2 products, surviving and thriving within this landscape have been easy.”

First of all, even though we entered the race late, we realized that most of the requirements of the PSD2 regulation can be serviced through the existing WSO2 products. Technically, all we had to do was wire everything together, add any missing features, and package an end to end solution which enabled banks to achieve full compliance very quickly.

We had to go for a very aggressive sales and marketing strategy in order to gain traction in a market that was full of different types of competition (not just our usual middleware competition). So we planned different types of campaigns to first create awareness and then engage with banks that were outside our usual customer base. Once we did the first few implementations, word got around and we were getting a large number of requests from both European and non-European banks.

4. Can you tell us about your experiences with customers who are trying to become PSD2 compliant? What are the key challenges they face?

Security is the utmost concern for all banks. Since it is sensitive customer data that is being exposed, banks that engage with us emphasize the importance of the ability to secure data and its access, above all other requirements. The WSO2 Open Banking solution overcomes all security challenges, since it incorporates WSO2’s very strong and proven IAM offering.

Most of our customers are also looking for ways to make their regulatory investment worthwhile, by being able to earn some revenues from their implementation of PSD2. With a digital transformation focused open banking implementation, our open banking customers are easily able to achieve this.

5. It seems obvious that banks will need to think beyond API when planning a technology strategy for compliance. How difficult/easy is to convince them to do so?

When we look beyond the regulation and discuss implementation details with each bank, the need to integrate with existing internal systems, the requirement for comprehensive Identity and Access management, the capability to onboard third party providers, and the necessity to have a strong analytics component to achieve regulatory reporting requirements comes to light. These requirements are usually enough for customers to understand the necessity for an overall technology strategy rather than just an API strategy.

However, we don’t just stop there. We understand that each customer (big or small) is making an investment to extend their technology platforms in order to satisfy these requirements. We help the customer identify ways that they can reuse the technology they are investing in, to further digitize and optimize their existing processes in a way that promotes market expansion and create new revenue streams.

6. What are your thoughts on how open banking will be adopted globally?

It’s only a matter of time before open banking becomes a must have for all banks globally.”

Well, all regions are moving towards open banking albeit at different paces. Australia is next in line to implement open banking through regulation and there are many other regions such as New Zealand, Hong Kong, Japan, etc., that have stated their intentions to mandate open banking through regulation.

In the meantime in all other parts of the world, even without regulatory pressure, individual banks are adopting open banking due to the many benefits they can achieve especially in an environment where they could be the first movers to a new ecosystem. Therefore, it is only a matter of time before open banking becomes a must have for all banks globally. WSO2 is excited and ready to work with each region on their specific open banking journeys.

7. Finally, as a woman playing a leadership role in a technology company, what is your advice to other women in the field on how they can reach the highest pillars of success?

I’d encourage more and more girls to join the IT industry, and contribute towards development of great products that are created by a diversified workforce for a diversified consumer base.”

I believe that being female does not have any disadvantages for a career in IT. Since women are the minority in this industry, it provides women a superb opportunity to easily standout within a male dominated workforce. Furthermore, the IT industry’s flexible working arrangements really enable us to balance work life and family life.

I would encourage more and more girls to join the IT industry not just to profit from its various benefits but also to reverse the gender imbalance and contribute towards development of great products that are created by a diversified workforce for a diversified consumer base. In fact, I’ve even written a blog post on the subject for the World Bank.

Seshika, 2nd from the right, Winner of the Young Engineer of the Year award for 2017 by IET Young Professionals-Sri Lanka

Three Months in to PSD2 – Confessions of the WSO2 Open Banking Team

It’s been 3 months since the PSD2 compliance deadline and the dust is settling in. Or is it really? Just like when it started, the post PSD2 landscape is viewed from different angles. It has been called everything from a ticking time bomb to a slow burn to a never ending honeymoon period. We think the biggest surprise was that everyone thought that January 13 was the end. It wasn’t, it was the beginning.

When we created WSO2 Open Banking, we knew customer needs would be diverse and every technology experience we deliver would be unique. Turns out we were right. Our journey with WSO2 Open Banking has unraveled some interesting experiences while working with different stakeholders in this compliance ecosystem. Here’s what we learned.

Confession #1: (Almost) Everyone was late to the party

Everyone (including us) started counting down to PSD2 from 6 months to 3 months to 1 month. But the reality was, January 13 was just the date when PSD2 was implemented by the EU parliament as a European-wide regulation.

Several regions across Europe chose to deal with imposing PSD2 in their own way. We’ve been tracking the country-specific deadlines quite closely and about 46% are yet to set an official deadline for compliance. We believe that the final date for compliance will be when the Regulatory Technical Standards (RTS) come into effect in September 2019. That’s good news for us because there’s still a large viable market for compliance technology! ;)

Confession #2: Compliance confusion did not discriminate

Over the past several months, we’ve worked with many banks of different sizes across Europe and they all had similar questions:

This led us to believe that banks, regardless of size, require a lot of guidance in the compliance process. It’s a good thing we have a team of experts to do just that!

Confession #3: They came, they saw, they vanished

When PSD2 first started gaining traction in 2016, the knee-jerk reaction of every API management and integration vendor was “this is a goldmine of opportunity we cannot miss”. So they went head on into the market with an existing product. Come 2018 when the need for compliance technology has evolved, these “first mover” technology vendors have gone quiet.

It remains uncertain whether it was the lack of a well thought out strategy to keep consistent market demand, fintech domination, or not giving the compliance market the attention it deserved. One thing is for sure, this is a highly competitive market for technology vendors like us. But no complaints, we love a challenge and are pretty good at winning them!

Confession #4: API standards (and the organizations writing them) are a solution providers BEST friends

A lot of shade gets thrown at not having a common API standard across Europe (version 1.1 of the Berlin Group API specification is yet to come, we’ve got our eyes peeled for that). However, Open Banking UK has got this in the bag by having a comprehensive API specification that WSO2 Open Banking supports.

When we first started out, these standards really helped set the base for building our solution. Our development team continues to spend a good couple of hours every week identifying latest improvements in the specifications and contributing to their development by participating in working groups.

Confession #5: Compliance is not a back breaker…it just needs a well thought out strategy

A lot of banks think of compliance as a major headache and seek a “quick fix” to compliance just so they can tick off the checkbox. The reality is, quick fixes can do more damage than good. PSD2 compliance is a big deal and if you go into it without a strategy, that’s cause for alarm. Even if you don’t have a dedicated open banking or compliance team you can still get the job done.

You just need to rally the right members, set your goals for compliance and figure out what you need from a technology vendor. Then you need to pick the technology that gives you value for money and won’t take eons to work with your systems and deliver compliance. It’s a matter of working closely with a solution provider towards a common goal.

Confession #6: Do your research or go home – The learning never stops

There is a minimum of 3 articles written a week on open banking. Everything from thought leadership material, opinion pieces (like this one), and publications from standards continue to explore and discuss this ecosystem. And what we learn from our conversation with customers is an invaluable source of research to keep abreast of where the market is heading. We treat each of these as a unique source of intelligence and they continue to nurture our product management, sales, and marketing strategies. It’s the only way to survive in an ecosystem as dynamic as this one.

It’s been a great ride so far and we can’t wait to see what comes up next! No doubt there will be plenty more surprises and exciting developments to look forward to!

The WSO2 Open Banking Team