Earlier this year, the next big marker in the life of the second Payment Services Directive (PSD2) arrived, as participants in the European regulation’s new API-based ecosystem submitted solutions for testing by both payment initiation service providers (PISPs) and account information service providers (AISPs). That will seem like a lot of acronyms for one sentence. But the real influence of PSD2 is far more philosophical in nature. Indeed, it may represent the biggest regulatory gambit that many tech junkies - outside of the payments space, anyway - have never heard of.

The question is whether PSD2 gains fame for its ambition, or infamy for the technology headache it may cause in the coming couple of years. A lot of once-reliable revenue is on the line, too.

Bold Intentions

Dig into the details, and the reasons why PSD2 matters become clear. Much of the regulation that came about post-crisis rightly focused on financial institutions getting their houses in order. Their general purpose was still to impose rules and constraint: compile, analyze and evaluate on a compartmentalized bank-by-bank basis before aggregating those results for takeaways on an industry level. It was more about getting a grip, and designing preventative mechanisms to ward off “the next one”, rather than opening up.

In fact, while it’s true that openness in data and technology has gained steam in the years since, it remains a touchy issue in regulatory design. For instance, we’ve seen endless righteous debate during the build-up of the US Consolidated Audit Trail (CAT) around the deployment and cybersecurity of newly-collected trade order and execution data. Many have also pointed out that just as PSD2 has gained steam, the European Union has pushed in another direction with its major privacy regulation, GDPR. Like most things in life, progress in open banking is far from linear.

But the shape of PSD2 states bolder and very different intentions. These include unleashing customer payments data to a broadly competitive and open ecosystem; using APIs as the foundational basis to achieve that end; and recognizing that emergent so-called payment “fintechs” in the space, like Ripple, need to be regulated effectively and fairly, just as legacy bank-backed giants do. No one can slight the crafters of PSD2 for their ambition, and as we’ve already broadly seen with GDPR, there is a strong chance that its influence will proliferate and globalize.

The implication here is that the future of regulation lies in engineering technology as the conceptual basis for solving market problems, as with PSD2, rather than as a tertiary means to an end. It’s a change in regulatory architecture. Less brick and mortar, and more new-age parametricism and exoskeleton.

Teething Issues

Still, just as many architectural critics wonder about parametricism, PSD2 works only if its final stages are delivered smoothly to a workable end-product. And as many banks and third-party providers (TPPs) have told us, it’s fair to say that is far from guaranteed. Even if firms are on board with the “open banking” concept behind the directive, the months leading up to effective implementation later this year will be variously expensive, technically complex and filled with testing. These teething issues could become, as one expert aptly summarized it, a “growth sector for lawyers” -- which no one wants (besides lawyers). And important questions around effective solution design linger, as well.

Let’s examine why these areas evoke both fear and potential opportunity. One of these lies in managing payments relationships under the new regime. Many say the work of PSD1, which was meant to bring order to an otherwise fragmented payments marketplace and help participants understand their obligations, is far from done. They will also need to sort out interchange fee procedures for consumer banking as they relate to the new regulation. PSD2 adds an insurance requirement to guard against growing risks like push payment fraud, which will make operating in the space more expensive. Structuring that protection remains an open question for many firms today. Equally, they’ll be trying to project just how much they stand to lose to incipient PISPs, and what rearguard actions to take, if any, to stem those losses.

The other area lies in technology, itself. The APIs’ design will necessarily reflect each payments provider’s perspective on the constraints mentioned above and for many participants, a high level of customization will result. The lack of API standardization will create a challenge for interacting in the PSD2 ecosystem. Simply adding more technology is no cure-all, and that is especially true for corporates and other entities that see no significant benefit to achieving a new tech spec, or only lightly interact with European markets. They’ll need partners.

Conversely, opening up the spigot of customer financial data via API should allow banks with smart developers and effective data infrastructure to build a valuable hose. Larger institutions can use their capacity to serve as data aggregators and third-party service providers (TPPs) to PISPs and other smaller banks struggling with PSD2’s new requirements, particularly those lying well downstream from the user’s point of access (like interchange fee processing and flagging up potential payments fraud claims). Open data availability should also allow those with ears up to create new applications faster, reflecting changing user behaviors or payment channels.

In the least, this could help mute incumbent losses as the new payments structure takes shape - losses estimated by Accenture at nearly 10 percent of all retail payments revenues by 2020.

Under the Hood

Of course, if it were that easy every legacy participant would be reacting accordingly. In some ways this could play a bit like the swaps market reform that came several years ago to the United States, which augured broad disruption with independently-owned swaps execution facilities (SEFs), only to ultimately see a select handful of incumbents take advantage with aggregation portals and other services (while many SEFs were scooped up over time). Just the same today, it is surely the case that some bank tech teams have looked at the pluses and minuses with PSD2 and simply decided to keep up, while others may jump ahead as first-movers.

For many, this will come down to what’s already under the hood. Those wishing to really take advantage of this (and future) “open” regulations will need to focus not only on the specific API and the software work required around it, but also on the way they manage, reconcile and secure the relevant data in question. It isn’t exactly forced technology transformation -- but it’s close.

PSD2 may prove a revolution; it may also be a mess in the short term. But this style of regulation is only set to grow in influence over the coming years as regulators are called to deal with tech-fueled disruption. Having a flexible data foundation will be crucial to keep up.