With stated goals of increasing competition, innovation, and financial inclusion, bank regulators across the world are mandating that banks open their systems, enabling consumers to share their financial data with third parties.

One touted benefit of this sharing is that it may create digital banking ecosystems that offer consumers more services than ever, provide banking information and capabilities in more useful and convenient contexts, expand the market reach of ecosystem participants, and boost financial participation among the unbanked and underbanked.

These benefits involve requiring that banks produce application programming interfaces (APIs) to make data and functionality easy to share with partners in a standardized way and to give consumers control over the services with which their data is shared. Because APIs enable developers to leverage and reuse software for new services and digital experiences, including by combining APIs from multiple providers, tech pundits and commentators often refer to the “API economy” — that is, to digital ecosystems in which companies symbiotically share and combine their software to create richer offerings, to complement their proprietary strengths with offerings from other organizations, to share innovation across enterprises, and to expand into new sectors.

Rather than being able to access and act on financial data only through specific channels, for example, consumers in an Open Banking world would theoretically be able to use their money across a constantly-expanding array of apps and digital experiences. Likewise, rather than being confined to one bank’s specific digital services, consumers would be able to opt into a range of services, such as better loan matching or debt reduction advice, to help them do more with their money. Banks, meanwhile, would not have to create all aspects of digital experiences themselves but could rely on external partners, which they can add at unprecedented scale via APIs, to shoulder some of the burden of attracting and creating value for customers.

The envisioned disruption is sweeping, but key questions for bank leaders and bank investors remain, notably the extent to which the Open Banking movement will exert significant, durable impacts on market dynamics — and the extent to which Open Banking compliance constitutes an effective market entry into digital ecosystems and the celebrated benefits of the API economy.

Put simply, is complying with Open Banking regulations adequate to advance a bank’s digital strategy?

Building compliant APIs vs. entering the API economy

Individual regulators are fundamentally constrained in their ability to give banks detailed instructions on how to behave in digital ecosystems. Mandatory regulations can be originally conceived with only one or two business models in mind, not the many thousands of business models that could be partially or fully enabled by the API economy. Detailed rules and specifications may threaten the functionality of services, as regulatory interventions that give highly specific guidance may not be system- and business model-agnostic.

In terms of policy, the willingness of regulators to force banks to adopt APIs is highly significant, but because these regulatory interventions do not offer a meaningful and durable market entry roadmap for banks to follow, the regulations may be an initial catalyst to prompt financial market evolution rather than a natural and enduring end-state for business activity.

Aside from the constraints at the level of the individual bank regulator, there is limited consistency among Open Banking regulations across the globe. Europe’s PSD2 was the regulatory intervention that kicked off this global wave, but there are small but significant variations in the ripple of regulatory actions around the world.

In Australia, Open Banking is part of the Consumer Data Right, an initiative to give customers the right to access their data in a machine-readable form — a right the country does not confine to banking. In Singapore, the Monetary Authority of Singapore is pushing for a lightweight regulatory framework regime. Japan’s Amended Banking Act introduced a registration system for third party providers. Korea’s Financial Services Commission has launched a Fintech Open Platform. Mexico’s recent law to regulate financial technology institutions lays groundwork for an Open Banking regime. The Central Bank of Brazil is aiming to implement the relevant regulatory reforms by the end of 2019. For the largest, internationally diversified banks, these regional differences further complicate any effort to regard mere compliance with these interventions as an effective and coherent market entry strategy.

Despite these complexities and ambiguities, I’ve observed in my work consulting with financial institutions that some banks nevertheless treat Open Banking compliance projects as a means of market entry into the API economy. This mindset could be a costly mistake and may leave these banks at a significant competitive disadvantage as we continue to accelerate into the era of digital ecosystems. In addition to compliance, banks should view a commercial entry into a foreign country as a useful reference for entering the API economy.

Entering the API economy is like entering a foreign market

Banks executing a commercial entry into a foreign country will encounter cultural differences, whether in the form of language, ethnicity, religion, social networks, values or norms. When these cultural differences are large, market entry into a foreign market is more difficult.

The practical implications of administering new business activity in a foreign country also impact the level of difficulty. The physical distance between the home country and the foreign country has to be managed. Border hardness, time zones, and climate also impact the administrative challenges posed by the foreign country. Additionally, the market landscape is foreign. New countries can significantly differ in their natural, financial, and human resources. Staff sent to build up a new division in a new country will have to cope with different levels of market Infrastructure, information, and knowledge. Finally, the economics of entering a foreign country can be heavily influenced by historical and political factors such as a shared colonial history, common memberships of trading blocs, and shared currency zones.

These patterns of differences and similarities can likewise be observed when a bank tries to enter the API economy.

Like entry into a new territory, entry into the API economy may pose sharp cultural and operational differences for banks to grapple with. In this world of APIs and software ecosystems, an API provider’s commercial aim is to make third-parties the dominant force for innovation — that is, to securely share data and services with external contributors who build new connected experiences that generate value for the provider, much as ridesharing companies have generated value by leveraging APIs such as Google Maps. Enterprises focused on ecosystem development market their APIs as products for developers so that new innovation can emerge organically, without necessarily being pre-planned. Investment decisions in the API economy are driven by a desire to help preferred ecosystems to evolve fastest. All of this may be a very sharp change in culture for many banks that historically have sought to be the dominant innovator shaping customer experiences.

The established approach to innovation in banks is highly deliberate, aiming to match bank financial products to specific customer needs and to beat the financial product offerings of peer banks. Compared to modern digital ecosystems, these legacy banks’ resources for, scope of, and receptivity to innovation may be considerably constrained. Banks that actively treat the culture of the API economy as very foreign to their traditional corporate culture have a far greater chance of acknowledging these challenges and making a successful market entry into the API economy.

Many banks may also face challenges transitioning to ecosystem administration models. In traditional banking models, the C-suite commands and controls the bank staff that distributes products. Typically, very few external business partners are involved, and those that are have generally been deliberately, if not laboriously, selected. In contrast, the API economy requires the orchestration of very large numbers of third parties that add value to a bank’s innovation and distribution capabilities. Literally thousands of partners may access a bank’s APIs to build services atop banking data, extend a bank’s functionality or insert the bank’s APIs into new business contexts. In many ways, the whole point is that partnerships don’t have to occur in slow-moving, methodically planned formal partnerships but rather can be achieved at Internet scale while preserving control over and visibility into customer data. This shift in strategy is no small departure for many banks — so again, thinking of the endeavor as entry into a foreign market, rather than something that can be jumpstarted via regulations, is wise.

Crucially, the market landscape in the API economy is also very different from what legacy financial institutions are used to. Traditionally, banks have segmented the market into very large market segments (e.g. consumer banking, corporate banking, private banking etc.). In sharp contrast, the API economy sees partners working together to serve market micro-segments that would not be reachable and profitable by each individual enterprise working in isolation. Simply put, addressing all customer needs, from mainstream use cases to niche applications, is beyond the capabilities of any single enterprise and can generally only be achieved through ecosystems and partnerships. Because partners working together in the API economy seek to serve the customer through the customer’s preferred digital interface (which may be different than bank’s preferred digital interface), ecosystem partnerships represent a massive shift in marketing management, with major implications for a bank’s business architecture, technical architecture, governance, and risk management.

Additionally, in the API economy, pricing decisions are generally driven by a desire for ecosystem growth. Partners work together to extend the customization and value that customers experience when consuming services. By design, the intellectual property in an ecosystem becomes dispersed. Banks have traditionally sought to protect the exclusivity of their intellectual property, and they have often sought economic returns via cost-plus pricing and minimal customization of financial products. Just as with other aspects of the API economy, these ecosystem dynamics and economic relationships typically fall outside a bank’s status quo operations and strategies — more akin to entering a foreign market than to simply satisfying regulatory requirements.

The C-suite should be involved

To approach entry into the API economy as they would approach market entry into a foreign country, banks should consider focusing on a small number of products or segments. They should seek complementary partners who can help them adapt their skills to the API economy and extend the reach of their core differentiating strengths. Just like entry into a foreign market requires combining elements of the home country business model with new local elements, banks will have to transform to increase the effectiveness of their ecosystem participation.

Because an Open Banking compliance project involves regulators specifying the scope and schedule for mandatory APIs, the C-suite may feel relegated to the role of budget provider, which may tempt executives to delegate the sponsorship and steering of the project. Such delegation is not an option for a foreign market entry, where all decisions on scope, cost and timetable are strategic and entirely in the hands of the bank itself — and the C-suite should not consider it an option for entry into the API economy. Bank leaders need to be involved, as the organization likely will not be able to make the necessary strategic and operational transformations if the vision is not defined and driven from the top.

If you’ve taken a trip in the past 30 years, then you’ve probably used Amadeus technology. Our solutions connect over 1.5 billion travellers every year to the journeys they want, linking them via travel agents, search engines, and tour operators to over 700 airlines, 110 airports, 580,000 hotel properties, 40 car rental companies, 90 railways, and more.

In 2016, over 595 million total travel agency bookings were processed using the Amadeus distribution platform. In addition, over 175 Amadeus airline customers processed over 1.3 billion passengers using Amadeus’ Passenger Service Systems. We combine an understanding of how people travel with the development of the most complex, trusted, critical systems our customers need.

A platform for scalability and speed

In today’s crowded travel marketplace, our customers want IT solutions that can scale up to match their complex needs—whether this includes solving the challenge of ever increasing flight search volumes, delivering flight search results in milliseconds, or enabling “pop-up” check-in and bag drop from anywhere.

Amadeus operates at large scale with hundreds of thousands of transactions processed per second to deliver mission-critical services in travel. Having a scalable and secure platform is essential to continue driving solutions for our customers, and Apigee’s API management platform fulfills this objective.

At the same time, our customers also want solutions that can adapt quickly with new features and upgrades. We’re talking days, not weeks or months. Apigee provides on-premise gateways to securely expose our APIs to our customers. These can be scaled to deliver our APIs according to our business needs. Apigee’s great capacity to create rock-solid API infrastructure gives us more freedom to focus on the architectural details of the technology we create for the travel industry.

A platform for collaboration

In the fast-paced and competitive travel industry, our customers hunger for new ways of doing things. This hunger can only be met with an open and collaborative approach across the sector.

That’s why we use an open systems architecture that offers SOAP/XML and REST/JSON formatting to be entirely platform neutral. It is totally independent of language and application frameworks, making implementation fast and efficient.

But as the number of customers using our APIs grows, so does the need to shorten the time to deploy our applications to market and evolve our API strategy.

The Apigee platform is key here. For one thing, it’s always up to date with constantly evolving industry standards, in particular with security standards like OAuth.

The platform also forms the backbone for the web app development cycle for Amadeus and our customers to jointly build applications and release them in production. Ultimately, by integrating Apigee’s control plane seamlessly with our APIs, we are able to foster fully automated operations.

A platform for visibility

Understanding how our APIs are consumed is also key for us and our customers. With Apigee we are able to see this and provide them with a detailed view of API analytics. In this big data era, knowing the number of transactions, response times on APIs, or the page travellers are spending the most time on with a mobile app could be invaluable to make the informed decisions that help us maintain an edge over competitors. This also serves as a great feedback tool to closely monitor where the industry is heading.

As a leader in travel technology, we’re committed to open systems. That’s why Amadeus also works with Kubernetes. We have a strong partnership with Red Hat through its OpenShift platform, which is based on Kubernetes. Amadeus Cloud Services works with this open-source system and enables us to use automated cloud methods to deploy our services in a flexible mix of private and public clouds.

We’re excited to collaborate with players like Google and Apigee, because together we can pave the way for technology that makes better journeys and creates value for our customers, travelers, and society.

Olivier Richaud is senior manager, API management & web services, technology platforms & engineering, at Amadeus. Xavier Gardien is head of portfolio and product management, technology platforms & engineering, at Amadeus.