Customertimes stands with Ukraine

Rethinking Your Open Banking Journey with MuleSoft

By Youssef Mounasser

PART I – FinTech Maturity & Open Banking Enablers

Before we dive into Open Banking concepts, it’s important to talk about what’s going on in the FinTech industry now.

According to Fundstrat’s report, Millenials + Money: The Unfiltered Journey, 92% of millennials, the largest single generation ever with an average age of 26.5, don’t trust traditional banks. In the last decade, start-ups, companies, and big technology firms have begun offering financial technologies (FinTech) that allow clients worldwide – millennials included – to interact differently with banks. As a result, banks are no longer the only players in the financial landscape. We have entered the era of FinTech 3.0.

Currently FinTech covers a vast number of services that are changing in the new digital era. These include:

To make these work for every generation, a collaboration between banks and companies should be considered as the best path forward for long-term growth. This is made possible with the introduction of Open Banking.

PART II – Open Banking Scopes, Objectives & Outcomes

Open Banking is the process of making the internal services provided by banks available to the external world so they can be used by third-party developers.

These include open, standard, and secured APIs. The goal is to provide services and applications based on existing financial institutions to the general population.

Now that the objectives are highlighted, we can consider two main designated Open Banking service categories:

  • PISP (Payments Initiation Service Provider), which allows the institution to execute a payment transaction on behalf of a customer.
  • AISP (Account Information Service Provider), which facilitates the connection to a bank account with the purpose of using that bank account information to provide a service.

To achieve these objectives, we need to understand the different types of Open API environments:

  1. Open Data: Financial data is supplied from a wide spectrum of sources

 

Authorized third-party providers can read transactions and other account related data

2. Open Process: Companies are authorized to perform payment-related operations

 

Authorized third-party payment management platforms can initiate payments

3. Open Products: Some account services are provided to the public

 

The customer can initiate a switch from one bank to another without being physically present

PART III – Open Banking Regulations & Compliances

Now that we have a clearer understanding of Open Banking concepts, we must consider regulations and compliances, as we are talking about highly sensitive data, and many questions will be raised around security, privacy, and data protection.

This is where local regulatory jurisdictions step in. They are tasked with determining a set of security and data protection requirements that every financial institution will need to comply with when implementing an Open API platform.

In the following section, we will provide examples of the Open Banking initiatives that various countries and regions have implemented.

UK: An initiative called CMA9 was announced in August 2016 and launched in January 2018. It involves nine institutions that represent 90% of the UK’s consumer and small business banking market.  Most of these Open Banking APIs are now available, and innovative new financial tools, services, and products are starting to become available.

As of January 2020, there are 204 regulated Open Banking providers in the UK, and the nation is regarded as a trailblazer, having set its own framework and API standard.

Europe:  PSD2 is a European regulation for electronic payment services. Introduced by the European Commission in 2013, it seeks to improve consumer protection and boost competition and innovation in the sector while reinforcing security in the payments market. PSD2 provides a clear definition of PIS (Payment Initiation Services) and AIS (Account Information Services), as well as new security requirements like the Strong Customer Authentication (SCA).

US:  Unlike in the UK, Open Banking in the US is more of an industry-led initiative, and it lacks the support needed from regulatory authorities to push for widespread adoption. However, the FDX (Financial Data Exchange) is attempting to set common global standards, and banks and FinTechs are holding discussions to decide on an approach to a data sharing regime. A number of banks have already created API regimes and provide Open API platforms for verified third parties.

Singapore: Many countries in Asia have adopted a prescriptive approach, allowing the government and central banks to play an active role in defining their Open Banking ecosystem. Singapore has taken a different approach, and as a result, the EPAA (Emerging Payments Association Asia) considers Singapore to be the leader in matters of Open Banking developments in Asia. The Singapore Monetary Authority (MAS) has provided a complete open banking framework and guidelines and have implemented initiatives like Finance as-a-Service that provide guidance to financial institutions and other FinTech players.

Australia: In September 2019, Australian Parliament approved Open Banking as part of the Consumer Data Rights (CDR) legislation. In July 2020, the first phase of open banking was deployed, allowing customers of the four biggest banks, which share 95% of the financial market, to securely share banking data with other accredited banks and FinTech organizations while giving customers control over how their banking data is used.

Japan:  Japan’s Banking Act was amended in June 2018 to promote Open Banking. They have enrolled around 130 banks that are expected to open their APIs in 2020.

PART IV – MuleSoft & Open Banking Implementations

The digital transformation journey should start with establishing a digital strategy. That can be achieved by answering the following questions:

  • Who are our users?
  • What practices do they perform?
  • What information do they need?
  • With whom do they interact?
  • What services are available to them?
  • What devices do they use?
  • Through what channels do they communicate?

Also, the program’s main players need to align the organization with the API-driven culture by:

  • Considering the APIs to be full products
  • Introducing new security considerations through an API-centric operating model
  • Reorganizing the skillset from a collection of independent systems to a federation

Once a clear digital strategy has been established and the scope of the Open API products to build has been defined, the financial institution will choose the appropriate integration solution by engaging in a products evaluation assessment.

Based on the requirements, a set of criteria must be defined to help score the available solutions. Some of the criteria to be considered are:

Initial cost and total cost of ownership (TCO).

Whether or not it’s a robust architecture with a high level of:  

  • Flexibility
  • Portability
  • Security
  • Scalability
  • Availability
  • Stability

How easy it is to deploy 

If the vendor can fully manage the SDLC lifecycle through: 

  • Integrated design tools
  • Increased development speed
  • Testing
  • Collaborative tools and the API portal

If they offer accessible training platforms

Gartner research advisory firm frequently publishes an API scoring quadrant based on a product’s ability to execute and its completeness of vision, and MuleSoft consistently receives high marks.  You can check the September 2020 Full Life Cycle API Quadrant Diagram here.

Consider Mulesoft platform …

Here are the benefits to using Open Banking implementations based on MuleSoft Anypoint:

MuleSoft Anypoint supports the entire software development life cycle (SDLC) — from designing, collaborating, building, and testing to deploying, publishing, versioning, and retiring APIs.

Anypoint supports the full API lifecycle on a single platform, eliminating the need to manage multiple products, vendor relationships, and skill sets.

 

Each individual API can be governed using API policies, and edge gateways can be implemented to allow for the application of global security policies across all APIs.

 

MuleSoft has designed the “Catalyst Accelerator for Banking,” which is a set of API designs and supporting reference implementations that codify integration best practices with a focus on PSD2/open banking, customer onboarding, authentication, and internal/external account aggregation.

 

Anypoint Exchange helps create API developer portals, viewing and testing APIs, and mocking to simulate data to APIs.

Customized Exchange public portals make experience APIs accessible to anyone using the internet, enabling developers outside of an organization to access that organization’s REST, SOAP, and HTTP APIs, empowering collaboration from the design phase.

MuleSoft recommends designing and implementing APIs according to API-led connectivity principles, which is a methodical way to connect data to applications through reusable and purposeful APIs. The point is to avoid a “Spaghetti” integration architecture introduced by the point-to-point connectivity model and increase development speed with a focus on the business outcomes of the API as products.

The APIs used in an API-led approach to connectivity fall into three categories:

  • System APIs – These APIs access the core systems of record and provide a means of insulating the user from complexity or any changes to the underlying systems. Once built, many users can access data without needing to learn the underlying systems and can reuse these APIs in multiple projects.
  • Process APIs – These APIs interact with and shape data within a single system or across systems (breaking down data silos). They are created without dependence on the source systems from which the data originates or the target channels through which the data is delivered.
  • Experience APIs – Experience APIs are the means by which data can be reconfigured so that it is most easily consumed by its intended audience. Data originates from a common data source, rather than from separate point-to-point integrations for each channel. An Experience API is usually created with API-first design principles and designed with a specific user experience in mind.

So applied to Open Banking, an API-led connectivity model could look like this:

 

APIs for Open Banking drive both horizontal and vertical integration and deliver several added benefits, including:

  • Automation
  • Lower operating costs
  • Unified experiences across channels
  • Speed to market.

Open Banking can appear daunting in the beginning for any financial institution. However, the right approach will ensure that outcomes are reached.

This approach includes:

  • Clear objectives and requirements definition
  • Open APIs culture evangelization
  • Strong and aligned solution design
  • Appropriate tooling and platforms
  • Experienced partners collaboration

Mulesoft is an incredibly valuable tool to be considered by anyone embracing this digital transformation journey.

It’s a best-in-class integration platform to connect data, applications, and devices across on-premises and cloud computing environments. In fact, customers using MuleSoft are able to improve team productivity by 300% and deliver projects three times faster than with Legacy or in-house connectivity solutions.

Customertimes is an experienced integration partner for MuleSoft, SAP, and many other tools with more than 15 years of experience delivering CRM solutions.

Our deep understanding of both ERP and CRM systems and processes means we are uniquely positioned to help customers maximize the value of their investment. We can help you make these changes and support you along the way.

Reach out to us directly at experts@customertimes.com to learn more, or visit our website.

Youseff Monassir

Youseff Mounasser, Integration Architect at Customertimes, is a system consultant with more than 10 years of cross-technical leadership in the implementation, validation, and deployment of large complex integration systems.