Loading ...
Techceler...
Business & Economics
Fintech
25
0
Open Banking
Try Now
Log In
Pricing
<p>WHITEPAPER Open Banking and the Future of Financial Services Are you a survivor or thriver? 2 Setting the scene Every day there is a new article that discusses the sea change disrupting the banking industry. This change, they say, will fundamentally disrupt the financial services value chain for customers, intermediaries, and incumbents alike. There is no avoiding the signs. Across the world there are pressures, both regulatory and customer-led, that are opening up the market to new entrants and disrupting what and how customers buy. In Europe specifically, the Revised Payment Services Directive (PSD2) is set to unleash a transformation in how financial services organizations view themselves, and each other. This isn’t unique to Europe - in the United States, aggregators such as Mint.com have already dis-intermediated banks and now own the ‘last mile’ of the customer banking relationship, disrupting traditional players. The success of Mint.com in the US highlights the appetite from consumers for account aggregation, or Account Information Service Providers (AISPs), in PSD2 language. Starting in 2006, it now says its customer base for its aggregation and personal finance services is over 10 million strong. Traditional banks are already feeling the competition with a number of high profile temporary bans on access to data from such services. Under PSD2, in Europe, this ban would not be legal; it’s only a matter of time before other global markets follow this route. PSD2, through both intermediating and dis-intermediating the bank, provides a legislative mandate for more open data and an increased open data interchange between financial services organizations. By January 2018, European banks must provide access to customer information (e.g. account balances and details) to AISPs, introducing another entity to the customer relationship. In addition, banks must expose customer information and payments services to Payment Service Providers (PSPs), dis-intermediating the traditional payments model. Most importantly, banks and financial services institutions may also take on the role of AISPs and PSPs themselves. This will all be enabled through the effective use of APIs; setting the scene for the API economy to play a disruptive role in the future of financial services. This need to drive a more open set of business practices will in turn accelerate the adoption of Open Banking. How organizations respond to this change will shape their future. Those that underestimate these waves of change may be survivors; but those who treat Open Banking as an opportunity to re-define and prioritize what value they add in the value chain will be thrivers, and will win, both short- and long-term. Common approaches to Open Banking With the rising importance of APIs, and banks waking up to the strategic implications, some typical approaches can be observed. The approach an organization selects depends on the organizational history, context, and, more importantly, how they wish to survive and grow. In particular, for large incumbents, where there are different lines of business and entities, they may be acting on more than one approach in parallel across the organization. The most obvious and prominent, at least in the media, is that of the Challenger; a new entrant who does not have an existing technology estate to ‘anchor’ them to a particular solution. Typically, they are selecting fit-for-purpose, often white labelled, platforms to quickly build capability and products. These are embracing and usually defining the opportunity for change and transformation, centered on providing a better customer experience in banking. The hurdle will be combining scale with this innovation. If and when this can be addressed, they are primed to thrive in the new landscape. On the other side, there are various approaches being taken by incumbent organizations, who have the scale already, but are trying to grasp the innovation that Open Banking presents. For some traditional large banks, a common route is to embrace existing technology investments completely and selectively transform these to compete effectively. For Transformers to be successful, the key element is ensuring that these transformation initiatives do not remain siloed. With the right abstraction, legacy platforms can ‘plug and play’ in the Open Banking environment but it is often costly upfront and can bear higher risk. Therefore, with little re-use of a platform or approach across lines of business then it could be a costly and ineffective way to compete. The same challenge applies to those organizations who are already running in-flight modernization programmes. These Modernizers have already “Open Banking is about making everything for sale. It provides a new way to increase digital revenue for the banks that are willing to think differently ... Open Banks and FinTechs will continue to erode margins and customer relationships for those banks that don’t.” - Kristin Moyer, Gartner, Research Vice President & Distinguished Analyst 3 made the decision to significantly update or replace core systems over the coming years and are anxious that an investment in PSD2 and Open Banking today shouldn’t be discarded in the near-term as their modernization programme progresses; how can they continue with wider investments whilst future-proofing their architecture for future technical standards. More radical, yet maybe the extent to which some will have to go to thrive, is the approach some banks are taking to build a complete new ‘digital’ bank outside the walls of the current infrastructure. These Revivers have recognized that they will never be able to, within reasonable constraints of budget and time, compete with Challengers using their current systems so are developing new operations and brands in parallel, which they can shift everything across to potentially in the future. Whatever the approach, traditional banks know that ultimately to compete, they must develop digital capabilities to avoid being dis-intermediated completely by new entrants with superior, more agile offerings. By helping their customers to manage their financial affairs, make better decisions, and save money, banks can drive deeper 'trusted adviser' relationships that ultimately will result in stickier customers as well as product up-sell and cross-sell. These organizations can take advantage of the opportunities that AISPs present and move from a transactional customer relationship to a more engaged, valuable and ultimately more profitable relationship. Three challenges to overcome Whether an established bank, new entrant or FinTech, how then should business and technology leaders respond? How can they simultaneously meet requirements to open data to third parties yet maintain differentiation in a hyper-competitive market? PSD2 is, after all, just the latest in a long line of initiatives that are putting pressure on banks. Refreshing core banking systems, developing digital capabilities, and responding to previous legislative mandates have already stretched organizations to breaking point. These initiatives are further complicated by the adoption of new technologies and new development processes. Against this backdrop, the most critical differentiator is often the speed at which the IT function is expected and can deliver on these initiatives. When it comes to approaching PSD2 and Open Banking, three challenges must be met: 1. Culture shift and future proofing of technology investments Open Banking and the use of APIs is fundamental and not to be underestimated. Some banks have chosen to embrace concepts such as R&D and innovation incubation teams, unbundling monolithic IT systems into reusable service components and hackathons to spark innovation in order to gain that agility. This may address today’s concerns, but how can banks build for tomorrow with uncertainty on the technical standards that will be defined in months and years to come? As described with the Modernizers, the last thing that any technology leader wants is to have to rewrite a solution in three years’ time because the technology they implemented today isn’t fit for purpose in the short or medium term. 2. Contributing value to and from the API economy The new ecosystem is comprised of not only financial institutions, but also retailers, high-tech companies, social media, crowdsourcing platforms, and potentially anything that involves financial information or transactions. In this new ecosystem, APIs are a new channel for doing business and need to be given that importance. The monetization of the API economy presents a new source of revenue, but only if a bank’s APIs are adopted and used by other organizations and developers. They should be productized and marketed as a source of competitive advantage, like any other traditional product. There is no value in having the best banking platform if developers don’t want to open the front door. Successful APIs require healthy internal and external developer communities and so APIs also need to be easily found, understood, and used. Banks need to both offer their services to be consumed by external third parties, but also think creatively how to use third-party services for their own offerings. Thriver banks will not only astutely open their own systems for others to consume but also look how to innovate and enrich their services by using other organization’s APIs. 3. Coping with increased, new and future demand Requirements for API platforms are numerous and future generations of customers will make new demands on these platforms that are unclear today. They must support security measures such as encryption, strong customer authentication and auditing to keep financial transactions and information secure. They must be scalable and efficient. When payments 4 are invoked through APIs and are revenue generating, poor availability and reliability are not an option. In a world where third-party partners are exponentially nudging a bank’s infrastructure with requests for payment permission and for live data feeds, the heightened risk of an overload on a bank’s network is very real. Banking-as-a-service: API-led Connectivity To address these challenges and harness the opportunities presented, a new construct is needed. API-led connectivity is an approach that defines methods for connecting and exposing your assets. API-led connectivity builds on the central tenets of SOA, yet re-imagines its implementation for unique challenges and opportunities like the one that PSD2 and Open Banking present. The approach shifts the way IT operates and promotes decentralized access to data and capabilities while not compromising on governance and security. It shifts the culture of the organization to one of reuse and composability. This is a journey that changes the IT operating model and which enables the realization of an application network, a seamless network connecting applications, data and devices. Figure 1. API-Led Connectivity in Open Banking Technically, from an IT perspective, while banks have largely built their IT on proprietary systems and ran dedicated in- house, over the years an increasing number of supporting and now core services have gradually been moved to private cloud or even public cloud infrastructure as well as reliance on the growing number of SaaS services operated by third parties. The cost/benefit ratio of leveraging a best of breed approach between internal and external systems operated on-premise or in the cloud leads-to an increased complexity in integrating heterogeneous components consistently, rather than point-to- point. Using point-to-point approach not only doesn't scale with the number of systems needing to cooperate one with another but also creates ever growing technical debt as additional complexity is layered on top of each other over time. From an integration perspective, given the regulatory and security challenges of a pure cloud approach, Hybrid integration is the way to progress at speed today. Hybrid cloud integration provides the perfect compromise, assuring that data from on-premises legacy systems can integrate with cloud data. Coping with new and increased demand, the third challenge aforementioned, is resolved as when capacity reaches critical levels, additional capacity can be spun up from the cloud rapidly. A mutual benefit, alluded to in the second challenge above, is that a Hybrid integration enables FinTech partners to be loosely coupled to your core platforms and systems but not so much that it requires lengthy on-boarding. This allows accelerated innovation as third party partners will be able to interact on an instant basis. In other words, it makes it easier for someone in the organization or developer community to create a useful application, use of data, or an experience API, and then expose that value to the wider network. Already, a handful of banks are leveraging their application networks to run hackathons with partners, including MuleSoft, to realize this vision, and to quickly create potential use cases. In API-led connectivity, whatever you create, to ensure the quality remains high, it crucially comes down to “Purposeful Design”. You need to always design with the consumption of data top of mind, APIs are the instruments that provide both a consumable and controlled means of accessing connectivity. They serve as a contract between the consumer of data and the provider of that data that acts as both a point of demarcation and a point of abstraction, thus decoupling the two parties and allowing both to work independently of one another (as long as they continue to be bound by the API contract). APIs play an important governance role in securing and managing access to that connectivity. This is why the integration application must be more than just an API; the API can only serve as a presentation layer on top of a set of orchestration and connectivity flows. This orchestration and connectivity is critical: without it, API-to-API connectivity is simply another means of building out point-to- point integration. This wouldn’t future-proof the solution and would provide limited short-term goals. You need to decouple and approach integration with layers in mind. This also enables true cost savings and increased efficiency as it minimizes costly re-engineering and design work at a later date. 5 ‘Three-layered’ API-led approach In this context, putting in a framework for ordering and structuring these building blocks is crucial. Banks have complex, interwoven connectivity needs that require multiple API-led connectivity building blocks. Agility and flexibility can only come from a multi-tier architecture containing three distinct layers • System Layer: Underlying all IT architectures are core systems of record (e.g. core banking system, key customer and billing systems, proprietary databases etc). Often these systems are not easily accessible due to connectivity concerns. APIs provide a means of hiding that complexity from the user. System APIs provide a means of accessing underlying systems of record and exposing that data, often in a canonical format, while providing downstream insulation from any interface changes or rationalization of those systems. These APIs will also change more infrequently and will be governed by Central IT, given the importance of the underlying systems. • Process Layer: The underlying business processes that interact and shape this data should be strictly encapsulated independent of the source systems from which that data originates, as well as the target channels through which that data is to be delivered. For example, in a purchase order process, there is some logic that is common across products, geographies and retail channels that can and should be distilled into a single service that can then be called by product-, geography- or channel- specific parent services. These APIs perform specific functions and provide access to non-central data and may be built by either Central IT or Line of Business IT. • Experience Layer: Data is now consumed across a broad set of channels, each of which want access to the same data in a variety of different forms. For example, a bank branch teller, online banking site and mobile application may all want to access the same customer information fields, but each will require that information in very different formats. Experience APIs are the means by which data can be reconfigured so that it is most easily consumed by its intended audience, all from a common data source, rather than setting up separate point-to-point integrations for each channel. Each API-led connectivity layer provides context re function and ownership: Layer Ownership Frequency of change System Layer Central IT 6-12 months Process Layer Central IT and Line of Business IT 3-6 months Experience Layer Line of Business IT and Application Developers 4-8 weeks; more frequently for innovation-led business Case study: Top 5 Global Bank Digital transformation is often considered as external to the firm. However, whether in terms of enabling transformation outside the company, or in and of itself, digital transformation is a powerful phenomenon inside organizational boundaries also. This multinational financial services company wanted to drive a firm wide architecture driving application development consistent with one of six best practice messaging patterns. This approach has initially seeded into one line of business. This success prompted subsequent rollout across 13 lines of business globally, connecting more than 1,000 applications in production. In the initial startup mode, the enterprise seeded adoption via a central group which was better able to seed adoption and prove out the approach. As the company continues to scale across the business however, it is looking towards API-led connectivity as the means to decentralize elements of the architecture to drive scale, yet maintain control. Central to the ability to realize this vision was a center for enablement which helped to codify knowledge and disseminate best practice. 6 Next steps Realizing API-led connectivity is not a discrete goal, but rather a continuous journey, much like Open Banking itself. Moreover, it is a goal that can be only be realized in incremental steps. Through partnering with dozens of Fortune 500 companies and four of the top nine global banks on their API-led connectivity and Open Banking journeys, we have distilled best practice into the following steps: 1. Start-up mode: In order for the API-led connectivity vision to be successful, it must be realized across an organization. However, in large enterprises it is simply not possible to wipe the slate clean and start from scratch. Consequently, the API-led connectivity customer journey must start with a set slice of the business, for a specific use case or for a specific line of business. By bounding the problem, the scope of change is reduced and the probability of success increased. Training and coaching to drive role modeling of new behaviors is critical at this stage. 2. Scale the platform: Once initial proof points have been established, these use cases will naturally become lightning rods within the organization that will build mindshare and become a platform to leverage greater adoption. In addition, the service oriented approach results in the natural creation of reusable assets which exponentially increases the value of the framework as the number of assets increases. 3. Shift to a Center for Enablement (C4E): Once scale has been established, it’s critical to quickly codify best practice and provide a platform for discovery and dissemination through the organization. The result of such a process is mass adoption across the enterprise. The core of this C4E may also be built during the start-up mode and scaled as required. For banks, the end result is a 2x to 5x faster time to launch new initiatives, connect systems, and unlock data across the enterprise and a 30% reduction in integration costs. This pace of change and agility is fundamental to an Open Banking environment, and with PSD2 and new competition acting as a formal starting point, building foundations now is vital. No matter which of the observed approaches is best for an organization, it has been proven that delivering on this vision through API-led connectivity supports both control and agility and helps organizations thrive, not simply survive, in this rapidly-evolving environment. MuleSoft’s mission is to connect the world’s applications, data and devices. MuleSoft makes connecting anything easy with Anypoint Platform™, the only complete integration platform for SaaS, SOA and APIs. Thousands of organizations in 60 countries, from emerging brands to Global 500 enterprises, use MuleSoft to innovate faster and gain competitive advantage. </p>
