PSD2 is a new legal structure for payments in the EU, based on a wide ranging set of articles and regulations to be applied to payment-related businesses. Of particular note to financial institutions, payment processors and global merchants alike are its provisions for third-party processor (TPP) access (often referred to as Access to Account or XS2A). With XS2A, banks must provide open access to regulated TPPs, allowing these TPPs to service customers directly. In return, those TPPs must meet a number of data security obligations, including support for strong (two-factor) authentication, as well as strict liability, transparency and customer service requirements. While PSD2 became live in January, there is a two-year window for adoption. Even allowing for leeway for some of the regulatory payment standards to be defined, PSD2 will become a reality across all EU member states before the end of 2018.
PSD2 echoes the disruption of the telecom industry in the early 2000s, when financial regulators forced large telecoms to “unbundle” services, creating a vibrant new market for the benefit of users. PSD2 will shake up European payments technology in a similar way.
It’s a very fast timeline, made all the more stressful by the fact that many of the regulatory technical standards (RTS) — the rules describing how financial transactions are secured, how partners are vetted and importantly, who is liable when things go wrong — have yet to be finalized. While the European Banking Authority (EBA) plans to produce final versions of the RTS this coming January, the current lack of concrete standards is leaving many organizations uncertain how to proceed. In fact, some are delaying compliance work until the final technical standards are finalized and the way forward becomes clearer.


Despite its acronym, RTS is unlikely to provide either “technical” guidance or a prescriptive “standard” for those waiting for greater clarity. The construct of PSD2 and the provisions for third-party access to banks’ systems are effectively a set of principles ready for immediate adoption. The implementation requires the adoption of collaborative techniques and technologies as used in sectors beyond financial services where personalized apps and service platforms have emerged to challenge older business models. The public policy atmosphere around PSD2 is set up almost like an incubator for new banking versions of Uber, Amazon or Airbnb.
The repercussions for those that delay implementing PSD2 are considerable as the EU’s idea is to advantage nimble, agile competitors (e.g., startups, FinTechs, etc.) so that more innovation can occur faster across the financial industry. Those that move fastest, show true innovation and bring successful business schemes to market will most likely have the most say over the emerging payment and compliance rules.
First movers will also be advantaged when it comes to bringing talent on board. PSD2’s January 2018 deadline means the better part of 6,000 banks across the EU will all be working to comply with the directive simultaneously, and consequently, be tapping the same unique talent pool to do it.
Consider the bandwidth of a top-10 systems integrator or consultancy. To take a bank with typical legacy back-end infrastructure and build the systems, software and business processes necessary to open that bank up in compliance with PSD2, a conservative staffing estimate is that it will require about 20 to 30 individuals working 40-hour weeks for most of the time left to comply. While some of the largest integrators may be able to gear up and handle such a project for one bank, how many can each do in parallel? Tens? Probably not hundreds? And with so many banks in the same difficult situation at the same time, those that get started first will likely be able to snap up the talent they need before it inevitably gets stretched too thin.
The faster all players move to open up their systems, gather up new partners and play an integral role in the PSD2 environment, the more successful they’ll be in competing in the new world of payments that the industry directives are aiming for and will almost certainly usher in.
Complying with the directive and then capitalizing on it, however, require a significant shift — both in technology and business mindset — for today’s financial institutions, many of which have legacy backend systems that were never designed to provide the real-time, flexible access to outside parties that PSD2 mandates. With no clear guidelines in place, it is important for financial institutions to be sure that whatever they implement will not only be compliant, but also position them to compete in the new environment.


Application programming interfaces (APIs) essentially let software developers link one software application to another, enabling the two to communicate and interact to develop new functions and capabilities. While PSD2 doesn’t specify any particular method or technology, the majority of the industry agrees that the best, most efficient method is to provide the secure access it requires via APIs. In the past, many businesses developed APIs to provide partners and other third parties with access to internal programs, but these were basically one-to-one, purpose-built connections that required lengthy development cycles and strict non-disclosure agreements (NDAs) just to get up and running. Each time a new business partner needed access, a new API would have to be created.
Open APIs, on the other hand, take that paradigm to a new level. They are designed to streamline the software integration process, enabling any business to build an API once, to expose key functionality and then publicly publish its availability so that any interested (and approved) party — be they a developer, a student, an entrepreneur, a bank, etc. — can use it however they see fit, with no proprietary interfaces or NDAs required.
A good example of an open API that’s widely used today is the “Log in with Facebook” button that many applications use to ease the login process for new users. Facebook offers an open API that lets any third party access its OAuth-based authorization system. This way, businesses can sign up new users without having to manage, secure and maintain their own identity management system on the back end, and at the same time the users get a seamless customer experience.
Some of the more well-known open APIs hail from platform-type businesses, like Facebook, Twitter and Amazon, but multiple examples abound in the nonbanking world. Consider how TripAdvisor’s mobile app helps users find a restaurant nearby and then offers to book an Uber ride to the location, or how a Groupon offer can cross-sell/upsell and tout a discounted ticket on Ticketmaster. These companies open up key functionality as a way to enhance customer experience, while driving business to themselves and their ecosystem partners. This is exactly what PSD2 aims to do.


Unfortunately, implementing open APIs isn’t as easy for traditional financial services firms as it is for digital startups or platform businesses like Facebook or Amazon. Most banks use complex core banking systems that have evolved over time with a variety of bolted-on solutions and less-than-elegant technology schemes. Revamping their systems to get the right data exposed in the right way in real time will be both costly and fraught with risk, since anything less than real-time insight into what’s happening in accounts serviced by TPPs will leave financial institutions dangerously exposed.
The move to open APIs also presents a number of cultural challenges for financial institutions. Banks are not only notoriously slow to innovate, but they are also often heavily siloed, making the required crossfunctional push into open APIs difficult at best. For example, who in the bank is responsible for defining and creating the open APIs? Is it the same group charged with publishing and marketing them? Who is responsible for maintaining the open APIs and evolving the resulting business models over time? Is it the core banking team, the payments software team or some other division? Additionally, you have the forever-divisive dilemma of “whose budget this activity will be taken from?”
Many will find it difficult to manage such a complex governance process across three or four internal teams, all of which will inevitably claim to have superior knowledge on the implications of implementing open APIs.
Some industry players may decide the mix of timeline, uncertainty, cost and organizational issues are just too difficult to surmount — never mind the mindset required to take key business processes and open them up to make them easier for competitors to duplicate and exploit. Those companies may feel that their approach to PSD2 will be to simply comply with the letter of the law and go no further. They will limit their PSD2 investments, create open APIs with only “bare-bones” functionality and be done with it, in effect, turning themselves into banking’s version of a “dumb pipe” or “a lame duck.” While their open API will not be very rich or used by many TPPs, they will continue serving their current, loyal customer base in the hopes that providing a consistent stellar service, albeit business as usual, rather than true innovation will suffice as time goes on.


Such a strategy may work in the short term, but what about five or 10 years down the road? It was no more than 20 years ago that organizations worldwide were presented with a similar business uncertainty, the advent of the World Wide Web. At that time, few could foresee the significance of the new technology, and many financial services firms simply decided to take a simplistic approach and outsource their web presence. Today, the web’s true potential as a business enabler is clear, and those firms struggle to provide efficient, collaborative, omni-channel experiences to their customers who now consider rich web functionality table stakes.

The world of PSD2 and open APIs is similar in that unless an open API is rich in functionality, wellmarketed and easy to adopt, few TPPs will decide to use it. And failing to attract a critical mass of TPPs means churlishly losing out on a wealth of opportunities across the financial landscape, including those for retail and commercial banks, payment processors and merchants.


The aim of PSD2 is that by opening up and implementing open APIs, all players will get a head start toward building new, innovative applications and services that will lead to increased competition as well as benefits for consumers. The banks, processors and merchants that win in this new ecosystem will be those that provide the most agile, flexible APIs, garner the most partners and successfully drive volume back to their business.


Today’s retail banks are getting hit and buffeted with competition from all sides. Consumers are using new payment schemes like Apple Pay or Samsung Pay, linked with cards belonging to competing institutions. New start-ups are offering innovative advisory, comparison or account aggregation services that are also drawing consumers’ focus — and wallets — away. PSD2 and open APIs provide a real opportunity for retail banks to put themselves back into the middle of their consumers’ financial lifestyles, and should be disregarded at an institution’s peril.
These banks can underscore their reliability, security and ease of use, all while providing consumers with rich new services and functionality. Say “Retail Bank A” has been in business for years and offers a wealth of banking services across online, mobile and other channels. It can additionally then offer an extremely reliable, intuitive way to log in to its services that will lead to its login feature being highly praised by all of its customers across the board.
Now consider “Jane Doe,” a customer of “Retail Bank A.” Jane also has a handful of other banking relationships, including a mortgage with “Bank B,” a joint account with her husband at “Bank C,” a car loan with “Bank D,” and so on. “Retail Bank A” can take advantage of PSD2 and open APIs by using the services it does well — ease of login — to better serve, retain and upsell to Jane — an opportunity that all institutions want to leverage.
Because PSD2 allows “Retail Bank A” to link up directly with Jane’s other banks, “Retail Bank A” can offer to enable her to use her “tried-and-true” login experience to access all of her other banking relationships, in effect providing her with a primary dashboard that allows her to more easily track her entire banking life and improve her cash management. Once that’s in place, “Retail Bank A” can gain visibility into Jane’s transactions at all the other banks and use that data to create and offer new services. For example, say Jane pays her car loan two days before her paycheck is auto-deposited to her checking account. “Retail Bank A” could see this and suggest moving the payment two days later to avoid potential loan fees. Eventually, it could upsell an offer to, in effect, become Jane’s financial and liquidity manager, a strong proposition that competitors will find difficult to match without the inside data.


Commercial banks have a similar opportunity to become more central to a wider portion of their corporate customer base, from the largest multinational to the smallest corner. Today, due to investment and servicing constraints, commercial banks find it necessary to limit high-level financial services such as cash pooling and liquidity management to only the largest corporates. With open APIs in place, however, commercial banks will find it just as financially viable to offer similar propositions to small- and medium-sized corporates as well, which tend to have less access to sophisticated financial planning and payment management services.
In addition, with PSD2 in place, both commercial and retail banks can provide their customers with new, innovative, leading-edge services, all without having to resource and fund every banking experiment that comes along. These banks can use open APIs to provide key functionality to new startups, providing the reliable back-end infrastructure they require and then partner with promising ventures as they emerge. Eventually, the banks with the most rich, flexible, agile APIs will attract the most partners, enabling them to offer their customers a wealth of new “sticky” banking products and services, many of which are simply unimaginable in today’s closed, non-collaborative banking environment.


Today, card processing is a tricky business to be in and is perceived by retailers as a bit like “death and taxes” — something that businesses need to do but resent because they are hit with hidden charges, sold to on a short-term basis and subjected to complicated back-end reporting systems. It’s “a race to zero,” as retailers continue to pressure processors to reduce rates and become as efficient as possible, leaving most processors continually chasing “scale” simply to tread water and keep revenue flat. Not only does this give payments a bad name, but it is also a faulty business model.
While PSD2 and open APIs bring a set of unique challenges to processors, since new forms of direct payment will compete with credit card payments for consumers’ front of wallet, they also provide processors with unique opportunities to escape the race-to-zero scenario, primarily by supporting (and enabling) a raft of new payment mechanisms.
For example, consider the rise of credit card payments itself. Prior to credit cards, consumers needed to be careful about planning vacations to be sure they had enough cash on hand to fund tickets, hotel rooms, meals and other purchases. Credit cards, however, made it far easier for people to make such purchases. In time, this new payments instrument (credit cards) enabled a whole new tourist industry.
PSD2 and open APIs enable much the same paradigm shift. Using the functionality available via open APIs, some players could begin to embed payments within new types of services and applications, such as a hotel app or bar/restaurant app. Consumers could then use those apps to tip their hotel valet or pay their bar tab, all without having to fumble with cash or run cards through physical machines, input PINs, sign paper slips, etc.
Embedding payments also helps improve online purchases. Today, consumers decide to make a purchase first, while browsing a website, and then must switch to an entirely different interface to pay if the payment page is hosted. Not only does this affect the branding experience of the customer, but it also risks adding another process that may cause the customer to lose interest and drop out of the sale before completion. With embedded payments, the purchase decision and purchase itself will become one and the same, streamlining the process and significantly decreasing the chances of abandoned carts. Processors that take advantage of open APIs and PSD2 to support/enable these new payment instruments will see significant upticks in customer gains and retention, since their wide support of alternative payment schemes can, in turn, help retailers influence consumer buying behavior and generate new revenue streams. Don’t forget that statistics show that the more payment methods that you have, the less basket abandonment occurs.
MERCHANTS: COST, CONVERSIONS AND DATA Merchants that embrace the promise of PSD2 and open APIs have a three-fold opportunity. First, as more consumers move to alternative payment forms such as direct-to-account, retailers will see their credit card processing fees reduced. While Europe in particular has regulated down such fees to as low as 0.2 percent and 0.3 percent for debit and credit card interchange, even larger retailers may still be paying 0.5 percent -0.75 percent when card processing and network fees are added to the equation. Reducing these costs could make a significant difference to a merchant’s bottom line.
Second, retailers are bound to see an improvement in conversions, as more consumers rely on accurate, streamlined forms of payment. Consumers that use reliable forms of payment that are always available and don’t require password resets, etc. are far more likely to finalize their purchases.
Finally, retailers can leverage open APIs and PSD2 to access critical data from banks, processors and other partners to gain new insights into consumer buying behaviors. By using that data to present the right offers at the right time to the right consumers, merchants will be able to target and retain the most lucrative customers, while significantly increasing store traffic and revenues.


Since waiting is not an option, the best route forward is to get started right away and start experimenting with open APIs and the different approaches to modify them for compliance in 2018 and beyond. All financial institutions must work quickly to ensure they have the right agility and flexibility in place, both “business-wise” and “technical-wise,” to embrace this new legislation.
FORFIRM knows the challenges that established financial institutions face as they look to comply with PSD2, create open APIs and make a play in this emerging world of innovative financial services. We have a track record of being ahead of the banking technology curve, and unlike most others in the industry, we have been honing our API strategy for years. Our Framewor is built “from the ground up” to expose key banking business services in precisely the way API gateways require. We can help ensure your business is best positioned to exploit the opportunities PSD2 and open APIs represent.