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.

Meeting the March 2019 PSD2 Compliance Deadline with WSO2 Open Banking

We’re reaching the final stretch of the PSD2 timeline. However, before targeting the final deadline, the Regulatory Technical Standards (RTS) also specifies an earlier deadline set on March 14, 2019. This will open doors to open banking by letting interested third parties explore the open banking ecosystem and start developing applications around it. As defined by the RTS, implementers should open up a sandbox environment ready to onboard third parties where testing can be done without exposing any sensitive information — a safe playground to kickstart open banking.

Regulatory Requirements

We’ll explore the essential building blocks that you’ll need to meet the March deadline. With WSO2 Open Banking it’s possible to meet these regulatory requirements out of the box and gain regulatory compliance in just over a month.

Open APIs

The main interface for consuming payment services is through APIs. Third parties bearing the roles of “payment initiation service providers”, “account information service providers” or both, will consume two types of exposed resources — accounts read-only API or payments read-write API.

Apart from exposing Open APIs, WSO2 Open Banking comes with fully-fledged API management capabilities that were positioned as a leader in The Forrester WaveTM: API Management Solutions, Q4 2018 report. This allows easy lifecycle management with pre-defined templates to support UK, Berlin Group and STET API specifications.

Strong Customer Authentication

The aforementioned APIs are protected with PSD2 Strong Customer Authentication (SCA) which is based on two or more authentication methods categorized under knowledge-based and possession-based factors. A solid SCA implementation will ensure that only authorized parties are consuming the APIs with explicit user consent.WSO2 Open Banking provides an out of the box SCA solution that is aligned with the PSD2 regulatory requirements. Also provided are identity and access management capabilities that allow seamless integration with legacy user stores.

Consent Management

The mediator between the Open APIs and SCA is consent management, which governs the access of user information by third-party providers. Access to this sensitive information is only retrievable with the user’s explicit consent. WSO2’s PSD2 compatible consent management module handles the heavy lifting while providing portals for customer care and self-consent revocation, therefore, allowing banks and users to manage their consent.

The task of consent management is to capture a user’s consent with fine grain details of transactions that ensures the user is informed of and has authorized the transactions. Consent can be of different types. For example, consent can either be given per transaction or for a recurring payment (where the consent is long-lived). The implementer’s consent management system should be able to handle a multitude of consent types while giving users and banks the ability to revoke and manage consent.

Transaction Risk Analysis

SCA provides a great layer of trust for open banking but handicaps user experience. This view was shared by many when the first drafts of the RTS were presented. The answer to this was Transaction Risk Analysis (TRA) — a context-aware rule-based system that makes sure SCA is exempted in low-risk scenarios thus increasing customer experience.

The solution ties TRA with a strong analytics and stream processing engine allowing accurate risk analysis and fraud detection. Proper implementation of this component is crucial to be PSD2 compliant and will promote better user experience with SCA.

Third Party Provider Onboarding (TPP)

The prior mentioned components build the fundamental open banking solution, but this won’t be any good if third parties are not able to onboard and consume its functionality. The system needs to be able to onboard third parties manually or through dynamic client registration, where third parties are on-boarded instantly with the backing of a competent authority.

WSO2 Open Banking provides customizable workflows for third-party onboarding and lifecycle management. External trust anchor integration allows dynamic client registration.

Regulatory Reporting

Each competent authority specifies certain statistical information to be reported regularly. WSO2 provides reporting tools to export required regulatory statistics.

Conclusion

By getting all these components together, banks will be prepped and ready for the external testing deadline in March. Additionally, this preparation provides strong guidance for meeting the September deadlines of the RTS. WSO2 Open Banking is equipped to help you meet both these deadlines within reasonable time frames and minimal effort from the bank.

For more information on how we can help you get ready for the March 2019 deadline, drop us a note at openbankingdemo@wso2.com. You can also download an effort estimate to understand how we can help you meet the deadline in just over a month and check out our webinar for more information.

Ask an Expert: Catching up with Ruwan Abeykoon

Ruwan, on the right, participating in a badminton competition in WSO2

If you bump into Ruwan outside WSO2, you’re most likely to meet him along a hiking trail or underwater, scuba diving somewhere in Sri Lanka’s southern coast. He’s also a vehicle enthusiast and loves technology. Inside WSO2, Ruwan currently looks into product stabilization efforts of WSO2 Identity Server that results in improving the overall architecture of the product.

In this interview Ruwan sheds light into his journey at WSO2 so far, identity and access management (IAM), and his view about software.

1. How did you enter this industry (was it by accident, why IAM)? Tell us about your journey at WSO2 so far?

Every change in my career was based on calculated decisions at critical junctures and I’m very pleased at how everything has turned out.”

I started off as an entrepreneur after grad school, working in the telecom and retail sectors. My expertise lies in telecom signalling and it’s been one of my interests for the longest time, in addition to high performance computing and IoT. Subsequently, I joined WSO2 where I was a part of the App Manager team, which is now the WSO2 Identity Server team. Every change in my career was based on calculated decisions at critical junctures and I’m very pleased at how everything has turned out.

2. What are some of the interesting projects you’ve worked on recently?

Adaptive authentication is one of the latest features we added to WSO2 Identity Server. What’s different about how we offer adaptive authentication is that it’s based on scripting language similar to ECMA. This is also involves user behavior analytics based authentication.

WSO2 Identity Server analytics is able to monitor login and logout sessions, and provide analysis based on a user’s behavior which helps with providing an additional security layer when authenticating them. This is what adaptive authentication is ultimately about.

Adaptive authentication is very important right now and not because of user convenience alone. Major financial institutions use adaptive authentication to provide advanced user experiences while providing Open-Banking APIs.

3. Do you see adaptive authentication as a game changer and how so?

People always want easy access to applications and systems. Making this process difficult means users will either move away from the business or they will have weak security methods. For example, enforcing people to use long and complex passwords can lead to them writing their passwords on a piece of paper somewhere, which isn’t a smart thing to do.

On the other hand, security experts want to limit access to resources and systems as well. Hence there is a need to find the right balance. And a need to detect risk and limit access while allowing free access for legitimate cases or users. This involves evaluation of many parameters and behaviors than simple static rules that are offered by most IAM solutions. In the future, we’ll also need to embrace AI on the authentication process.

4. What trends do you see in the IAM market? Where do you think we’re heading?

I’m going to provide a very brief overview of some trends that I’ve observed. For one, there’s an increasing dilemma between whether or not we should opt for a centralized IAM system. But given privacy concerns, it’s quite evident the IAM industry is heading towards a decentralized identity and access management system. Another trend is sovereign identity, where an individual decides what can be done with an identity. Although there’s a growing need for increased privacy, people must be able to share and delegate easily. Another is space-time-bound edge device security with identity of a person.

5. We now keep hearing that IAM is an enabler and it’s more than just security or an IT project. What’s stopping enterprises from embracing this? Why do you think they should?

It is easy to start an IAM system with a homegrown solution of simple databases. There are a plethora of libraries available to kick start a homegrown IAM system. But it gets into an inescapable vortex when more and more functionalities are needed in today’s agile businesses. Enterprises need to detect this at an early stage and adopt a proper IAM solution before the vortex grows into an unmanageable beast by itself.

6. Two things you’ve learned in your career that you’d like to share with a newbie?

Think of software as a medium of communication between both systems and people.”

First, think of software as a medium of communication between both systems and people. This could be system to system, system to person, and person to person. Second, learn to unlearn. No software practice has lasted for more than a decade. New languages and methods keep propping up and your openness to learn is what helps you progress.

Ruwan on one of his many scuba diving adventures!