OPEN ACCESS HOW PSD2 AND API BANKING OFFER OPPORTUNITIES FOR CREATING VALUE AND DRIVING BUSINESS IN AN OPEN AND INSTANT WORLD

Transcription

1 WHITE PAPER OPEN ACCESS HOW PSD2 AND API BANKING OFFER OPPORTUNITIES FOR CREATING VALUE AND DRIVING BUSINESS IN AN OPEN AND INSTANT WORLD

2 CONTENTS 1 New Ways to Create Value 4 A New Customer Segment 5 Putting the Customer in Control 5 FIS Open Access 10 Key Success Factors

3 Open Access API Banking 1 New Ways to Create Value Opening up to innovation The European Commission s upcoming payment service directive is a new generation of banking regulations. Instead of the normal prohibitions and limitations, the overall purpose of PSD2 (Revised Payment Service Directive) is to inspire banking innovation and create an even playing field in the payment space. The driving force behind the initiative is that customers own their data, not the banks. Consequently, under the XS2A (access to account) rule, PSD2 states that banks need to offer payment services to thirdparty providers (TPP) through an application programming interface (API). A more dynamic landscape The advent of PSD2 begins an era of unprecedented openness in Europe. Account Servicing payment service providers (PSPs) are obliged to provide customer account information to regulated third parties on demand. Furthermore, banks will be expected to accept payment initiations from channels owned by these third parties. The services offered to third-party service providers must be as responsive, transparent and secure as the banks own channels, with identical service levels for all no discrimination. With the injection of third-party services, innovation can flourish and grow, driving more transactions and additional payment use cases that could not be possible without external intervention. However, financial institutions cannot charge any fees for these services. Providing secure API access to systems that were once closed is costly, and banks are actively seeking ways to monetize the services in order to justify the investment. The drivers for open access Rethink customer channels Allow customers to choose how they interact with you. Direct or Indirect access via 3 rd party apps. Rethink customer acquisition It can be a path to acquiring new customers, not just retaining existing. Innovate faster... cheaper Embrace the 3 rd party developer community to innovate faster and cheaper than you can yourself. It will be better to disrupt yourself than be disrupted unexpectedly. OPEN ACCESS Ready or not... The API-app-driven economy is here. Europe will be the first with legislated open access. Other markets will follow sooner or later.

4 2 Open Access API Banking New three-way customer paradigm Customers will be able to conduct many of their banking services through applications developed by external third parties. This creates new roles and relationships within the payment landscape: banks will be processing transactions initiated on channels they have no control over, and where they do not exclusively own the customer. In addition to the traditional bilateral relationship between bank and customer, there is now a new three-way relationship dynamic between the bank, end customers and the third-party providers. This ecosystem needs prudent management. Financial institutions need to consider how they will manage the entitlements for third parties, and how to apply any limitations or restrictions on access to the bank APIs. Customers will be able to actively give, deny and revoke consent for any third-party application to access their banking information. Also, consent is mandated before any third-party app can initiate payments, according to any limits on transaction value and volumes set by the consumer. By offering customers total control over which app has access to what information through fine-grained consent models, banks remain the focal point of the relationship and the trusted party. Bank needs To facilitate integration with third parties To know who the third party is To implement the right level of security To find the right balance between trust and access/limits To have customers and third parties move to self service To monitor security risks and act quickly when needed Customer needs To be in control of which third-party apps to use To be able to manage and control limits for these third parties Bank grade security To share their credentials with nobody except for the bank Third party needs Easy integration A sandbox and developer portal to create new apps and test Well documented APIs To implement an appropriate level of security

5 Open Access API Banking 3 Above and beyond While accepting that the PSD2 regulation is mandatory, it should be noted that basic compliance is just a springboard. PSD2 simply levels the playing field for all but there is no reason why banks should not get some star players on their team and try to win. Widen the net Compliance states that the bank APIs should provide access to authorized and regulated third-party service providers, but what about the vast collection of app developers not on the approved shortlist? By allowing non-regulated third parties to access the bank s public (not private) API, a larger and far richer pool of imaginative talent can bring their innovative ideas to the banks solution portfolio. When dealing with non-regulated third parties, the banks will determine what access rights they will grant on a case-by-case basis. In addition, many banks are looking to use contracts with third parties in order to manage risk. Service offering The API that banks must make available only needs to provide the most basic information in order to meet the PSD2 standard. However, banks are free to define their own standards and can implement additional API services to be made available to third parties in order to create far more compelling and engaging services. Scaling the unknown A fundamental issue when defining the business case for API services is that of volume how many people will enroll, how many third-party developers, how many apps, how many API calls, etc.? The hard numbers are little more than informed opinion. Therefore, the ability for any API solution to scale is vital to success. Response times and service levels are increasingly important in a real-time world of instant gratification. Consequently, APIs need to be able to respond instantly to external requests without encountering information-flow delays that might occur if back-office systems need to be consulted. API services operate in a 24/7 environment and so need to be always on. It is vital that the infrastructure supports API availability at all times downtime is not an option. Moreover, the performance of the APIs will impact the enduser experience. Badly performing APIs lead to lower customer satisfaction and this not only impacts the service the third party is able to provide around the APIs, but also has a negative effect on the bank s reputation. The existing back-office systems are typically not equipped to meet these always-on, high performance requirements.

6 4 Open Access API Banking A New Customer Segment In a traditional banking environment there are two primary stakeholders; the banks and their customers. Post-PSD2 will see the addition of third parties to the mix, but does this fundamentally change anything? Currently, banks offer products and services to their customers in the form of financial products and information and advice services. The new third-party relationships are similar; banks offer third-party app developers products and services in the form of API access to customer services. Effectively, the third parties are just a new customer segment. The only concern for the bank is which products and services need to be offered, and to which third parties. More than a hackathon The first steps into the world of open-api banking encouraged app developers to reimagine banking services and create innovative customer services based on basic account information and payment initiation capabilities. The open sessions, often dubbed hackathons, helped set the stage for a wholesale shift towards third-party apps becoming the new public face of the bank channels. And conditioned banks to the reality that third-party developers, from large fintechs to individual creatives, are more than partners, they are customers that need to be catered to. Customers Distribution Opening up Creating new and compelling financial services based on banks customer data requires support. Banks need to review their operations model to cater to the requirements of a modern development community. Providing API access does not mean that anyone with an internet connection can start developing and releasing applications using any bank s customer data. Third-party providers need to be registered and enrolled into the scheme, and the access level they receive needs to be managed. Banks will be able to intervene at any time and lock down access in cases where a third party breaches the systems, or if a third party is itself breached. The developers also need technical and software support in the form of manuals, online forums and even helpdesks. Banks have a vital role to play during any disputes arising from a third-party app. Consequently, extensive logging and statistical capture and analysis will be required to ensure transparency of operations. With a new customer base of developers, comes a new community that needs to be cultivated and enticed through service excellence. Banks will also be able to differentiate their offering to the various developer segments: simpler open access services for apps that focus on retail person to person (P2P) services, compared to richer APIs for integrating with complex third-party enterprise resource planning systems. The third-party developer community will typically demand a fast response to changes. Therefore, banks need to be able to continuously improve and adjust their API interfaces to support rapidly evolving requirements. This is hard to achieve with existing back-office systems that have longer cycles of change. Banks need to find a way to support these two speeds of change. API API API Products Product Manufacturer REAL-TIME PAYMENTS APIs are a must to cater to real-time payments and to deal with new digital overlay services

7 Open Access API Banking 5 Putting the Customer in Control The most fundamental change emerging from the PSD2 open banking initiative is that the customer becomes the owner of their own financial data. Just because a financial institution maintains transaction histories on behalf of their clientele does not mean they own customer information stored on their servers. Through the application of an API interface, the customer can delegate that different subsets of their financial history be made available to specified third parties. Also, permission can be given to initiate payments from third-party applications. This heralds a new era of cooperation between the bank, third parties and their customers. With a new wave of convenient and flexible financial services, fully controlled and managed by the customers, trust is built as a mutually beneficial dependence develops. It is vital that banks remain highly visible during the onboarding process by actively facilitating the customer relationship with the thirdparty app developers that will be using their services. The customer will likely need to register and download a new app and therefore needs to be confident that the service is safe, secure and transparent. Retain and attract Customer control is manifest in a web of consent. Consequently, banks need to offer customers full finegrained control on these consents. The bank accounts linked to any services, along with any time restrictions and transaction limits for each permissioned third party, need to be controlled and managed through easy-to-access tools. FIS Open Access Opening up payments with API banking The FIS TM Open Access solution aims to open up the banking environment for your customers through a highly secured Open Access layer. The Open Access layer can be used to support public APIs on external channels as well as internal bank APIs through their own channels. Bank customers will be able to use third-party apps that give them direct 24/7 connectivity to a wealth of financial services. Third party access to banking and payment systems is stringently controlled, but provides all the services needed to develop innovative applications. Customers access is similarly managed. An API gateway is not enough Supporting third-party banking apps with API access to customer accounts requires more than just an API gateway. The API gateway itself provides a managed service that makes it easy for developers to create, publish, maintain, monitor and secure APIs. As such, the gateway is a vital part of the larger API banking solution but it does not cover the entire scope. The Open Access layer provides the API implementation required to comply with open APIs. It also manages the finegrained entitlements and consent agreements between the bank and the third-party developers and customers. No app can request customer information without the express consent of the customer, and the Open Access layer strictly controls what information is made available to third parties. By putting the customer in control, the bank actually will be able improve the customer relations and generate more interactions. This is a way to keep existing customers and attract new ones, and also increase the number of promotion and sales opportunities.

8 6 Open Access API Banking An enabler layer FIS Open Access insulates established payment and backoffice systems from the rigors of 24/7 real-time access. All API channels are managed from the Open Access layer that will respond to all queries directly implying minimal impact on the established infrastructure. Delivering these API channels requires banks to implement a digital architecture running alongside their existing backoffice applications in order to deal with the more frequent changes that will be required for API channels. A two-speed architecture enables banks to continuously develop their external facing APIs at a high speed while decoupling their back-office systems that typically have higher governance and a slower speed of change. While the advent of the API era is not in doubt, what is less certain is how quickly will the services become accepted. The volume of transactions and number of queries that will be coming through the API interface is not yet known. Where banks would typically roll out new channels gradually, it is hard to predict API usage by third parties and it also depends on how popular the applications are. Therefore, the Open Access layer shields downstream systems from unpredictable messaging rates and likely spikes in usage that could cause system overloads. FIS Open Access ecosystem FIS offers an API implementation with fine-grained access control. The technology platform has been designed from the ground up as a cloud-native application offering instant access to all approved third parties and end customers. The Open Access layer is highly scalable to combat as yet unknown message and transaction rates. All internal processing is based in the ISO standard. API endpoints can implement with different protocols and formats with little or no impact. API component Payment initiation and account information APIs are central to the solution. They can easily be extended to support additional value added APIs as required. Processing within the API can range from basic to advanced, depending on implementation choices. Three-way agreement Open Access maintains a three-legged agreements model combining bank to third party to customer authorization matrices in order to fully control access. API functional domains The FIS Open Access layer enables three fundamental API access domains. 1. Account information Gain access to customer account transaction history (only with explicit consent) 2. Payment initiation Make money transfers directly from consumer app Aliases supported so consumer can remain anonymous Option to level-up the security to include transaction authorization challenge 3. Web hook callback Provision of additional information push options to support third-party service provider

9 An API First Ecosystem Open Access API Banking 7

10 8 Open Access API Banking Customer to third-party service provider consent model customer consent The PSD2 clearly puts customers in charge of their data so explicit customer consent is required for access by thirdparty service providers. Open Access stores all customer consent given by a customer to third parties. With finegrained authorization control, customers are allowed to fully control transaction limits and define the timeframe the consent remains valid. Which third party can access which bank accounts, and which operations and specific actions can be performed. Open Access maintains a sophisticated consent map to control all access rights each customer specifies through an integrated OAuth2 flow. Bank to third-party service provider agreements model third-party agreements model Third parties create and edit agreements through a selfservice portal once endorsed by the bank. The bank itself can view all third-party agreements, endorse new or updated agreements as needed and suspend any thirdparty agreements instantly. Bank to customer agreements and entitlements model customer entitlements The long established bank to customer relationship already has numerous existing agreements; which customer accounts can initiate payments, what payment types apply, daily/weekly limits, etc. These established agreements are carried forward into the open banking era. Accordingly, Open Access can integrate with existing bank systems to fetch customer entitlement information as needed. Open Access API solution

11 Open Access API Banking 9 Integration with existing systems Open Access cannot operate in isolation. As such, a number of interfaces need to be made to existing back-office systems. As the Open Access API captures payments initiated via the third party they are submitted to the existing payments engine for processing. The Open Access API requires access to the account management system (AMS) for account information. The solution uses the existing identity and access management (IAM) solution at the bank to authenticate the user in the Consent App. Given that Open Access exposes the customer consent matrix, the bank may consider integrating to an e-banking module to act as a portal where customers can view the consents they have given to third parties and modify or cancel as needed The solution can integrate with any existing customer management application that stores the customer entitlements. Information exchanged typically includes the accounts that are eligible to be accessed via a third party (e.g., payment accounts in case of PSD2, but banks could choose to also open access to other account types), limits that apply on payments, supported payment types, etc. Rounding out the total solution with off-the-shelf solutions Commercial off-the-shelf solutions can be leveraged to compete the total solution. An API gateway component provides the access point for the third-party applications. The gateway is responsible for course-grained authorization of API calls, in collaboration with the OAuth server that manages and verifies the OAuth tokens. A developer portal, may be part of the API gateway package, allows third-party developers to create applications, register new apps, consult API documentations, and configure sandbox and test environments. A bank branded app store is recommended to ensure customers are directed to the best approved apps. This could link to the Google Play, itunes or other app stores. Security In a public API world, security is key. In order for banks to be able to assess risk levels, the APIs exposed to the market need to be able to capture additional data around the device used, location, etc. The Open Access API also offers step-up security, which means that we can automatically increase the level of security as circumstances dictate; i.e., there may be a requirement for a stronger authentication method in case the risk level of a transaction is too high.

12 10 Open Access API Banking Key Success Factors Open Access from FIS provides the basis of a future-proof API-based banking environment, but a successful implementation with strong customer uptake demands looking beyond simply complying with regulatory constraints. It is important to ensure providing open access generates revenue through the provision of extended paid services to the new third-party providers, but success will ultimately depend on customer acceptance of the technology. Control, trust and scalability The goal of the exercise is to put the customer back in control with fine-grained permissions control. Trust will be built through the implementation of strong authentication and a quick response time. Scalability is vital, but without knowing the likely service level requirements solutions need to be built from the ground up to ensure expansion potential. Real-time payments Regulatory changes do not dictate the payment instruments that must be used in association with app-initiated transactions. But customers have grown accustomed to a real-time environment and expect payments to be immediate. Therefore, to maintain a competitive edge, coupling Open Access payments into an established realtime payment mechanism is strongly recommended. Your developer community The inclusion of third-party service providers into the banking channel mix under Open Access obliges banks to provide their new developer community with the tools to do the job. The more app developers using the service, and the robustness of those apps, will directly impact the success of the initiative. The developers need access to the appropriate tooling, full documentation sets and an extensive support organization that is tailored to deal with third-party developers. And remember, there is every reason to expect the third-party service providers will be a very international clientele that may impact the support services on offer. An interesting additional service is the provision of web hooks that allow third parties to receive pushed updates on account actions rather than insist on the apps making excessive numbers of calls that could impact system performance. PSD2 is only a starting position From a European perspective, conforming to basic PSD2 will not be enough to maintain a differentiated position on the market. Go beyond. Consider implementing value-added services for third-party providers by offering more compelling capabilities. The bank can decide who has access, so it is recommended to keep the net of partners as wide as possible. PSD2 dictates supporting authorized thirdparty providers, but consider opening up services to nonregulated developers.

13 About FIS Corporate Solutions FIS offers a leading liquidity and risk management solution for corporations, insurance companies and the public sector. The solution suite includes credit risk modeling, collections management, treasury risk analysis, cash management, payments system integration and payments execution delivered directly to corporations or via banking partners. The solutions help consolidate data from multiple in-house systems, drive workflow and provide connectivity to a broad range of trading partners including banks, SWIFT, credit data providers, FX platforms, money markets, and market data. The technology is supported by a full range of services delivered by domain experts, including managed cloud services, treasury operations management, SWIFT administration, managed bank connectivity, bank onboarding and vendor enrollment. About FIS FIS is a global leader in financial services technology, with a focus on retail and institutional banking, payments, asset and wealth management, risk and compliance, consulting and outsourcing solutions. Through the depth and breadth of our solutions portfolio, global capabilities and domain expertise, FIS serves more than 20,000 clients in over 130 countries. Headquartered in Jacksonville, Florida, FIS employs more than 55,000 people worldwide and holds leadership positions in payment processing, financial software and banking solutions. Providing software, services and outsourcing of the technology that empowers the financial world, FIS is a Fortune 500 company and is a member of Standard & Poor s 500 Index. For more information about FIS, visit twitter.com/fisglobal getinfo@fisglobal.com linkedin.com/company/fisglobal 2016 FIS FIS and the FIS logo are trademarks or registered trademarks of FIS or its subsidiaries in the U.S. and/or other countries. Other parties marks are the property of their respective owners