The Open Banking Operating Model

With open banking, a new era in the financial industry is emerging. The productive launch of PSD2 in September is an important step towards establishing a larger open banking ecosystem and increasing the B2B share of a bank’s operating model. Banks have taken on a new and additional role as infrastructure providers. We would thus like to propose a slight change to Bill Gates’s famous quote “Banking is necessary, banks are not”: banking is necessary, but a direct bank-client relationship isn't! The value chain and role of banks is evolving following the launch of open banking, and some may soon find themselves reduced to being nothing more than infrastructure providers. Banks’ operating models will not remain untouched by this evolution.

Evolution of open banking

To understand the complexity of how to establish and run open banking within a financial institution, let us take a brief look at the pieces that make up open banking. At the moment, there are three use cases running productively in the UK and EU markets:

• Payment initiation
• Account aggregation
• Confirmation of funds

As simple as those services seem, the complexity behind them is immense. For most banks, open banking will consist of a run the bank(RtB) component and a large change the bank (CtB) component in the coming years. Some banks will probably choose to use their open banking CtB team to extend the scope beyond current accounts to investment, lending and mortgage positions. This extension in scope will allow these banks to charge small fees to TPPs as long as this additional scope isn't mandated by a regulatory authority. However, even banks that choose to stick with the three use cases listed above, and hence with the minimal regulatory scope, will need to adapt to new releases as set forth by OBIE, the Berlin Group, STET and other standardisation bodies if they are to stay relevant. This year has shown that those version & release upgrades^[1] must be completed within a given timeframe and, in addition, often require continued support for the older version for a given period. The combination of these demands together with the architecture requirements discussed in our previous article requires a relatively agile end-to-end setup within the bank and profound knowledge. As end-to-end availability of the solution must be near to 100%, and some tasks require manual fall-backs (e.g. TPP support and onboarding), typically the bank’s operations team must be able to support open banking 24/7. On top of this, new reporting requirements have been put forward by national regulators. Some of these reports contain availability and response times of REST API endpoints, effectively requiring the bank to monitor APIs with near-real-time monitoring tools. Finally, banks that want to access other banks’ APIs will need to connect to several different technical standards (cf. OBIE, Berlin Group and STET references above). There are currently seven major open banking API standards. While these can communicate with each other, they will nevertheless make interbank connections even more complex.

Does your bank have a team that can deliver all of the above?

^[1] Enhancements to the standards, especially reporting requirements and operationality, are part of the EBA work programme 2020.

Run the bank

The RtB team of open banking has to master several important tasks to ensure a compliant and highly available solution for clients.

Incident management

In order to qualify for an exemption, a bank must deliver proof of a functioning incident management process. This starts with a fairly simple tool: a ticketing system available to existing and future third parties to report any errors to the bank. The bank must then ensure that reported issues are picked up in its incident process and solved within a given timeframe depending on severity, i.e. obligations similar to SLAs in contracts must be fulfilled.

Support and TPP service desk

The new B2B interactions of open banking require an additional form of support. As we expect that most TPP questions will concern TPP onboarding and erroneous end-customer journeys, we recommend building up a TPP service that covers the following areas, among others:

• Technical knowledge of the open banking solution and providers,
• Understanding of the regulatory provisions,
• Understanding of the support model in your own organisation where open banking will be partly integrated,
• Knowlege of the open banking ecosystem.

A team with these skills is suited to answering the expected questions on technical issues raised by TPPs. The complexity and scope of open banking can only be covered through a team effort within the bank.

Reporting

Last but not least, open banking calls for comparatively detailed reporting. Some of the reports must be submitted to the regulator, and some must additionally be published on a public website. In order to report the proper data, near-real-time API monitoring tools are required (cf. above and article 2). An RtB function within the open banking team must be responsible for guaranteeing a continual monitoring system, gathering data from the monitoring system, double-checking their accuracy and quality and processing them in a form that satisfies the regulator.

Change the bank

The CtB component of open banking consists of all enhancements to be made under open banking, be they known upgrades or as yet unknown enhancements for which the team must be prepared.

Additional services

Many banks have gone live with just the most basic, mandatory open banking services. In order to reduce friction for end users, make them more reliable, enhance them and add new solutions, a separate team is needed. This team will play a vital role in the bank’s success in the open banking ecosystem.

Supplier integration and management

As the name open banking suggests, opening APIs allows new market players to consume your APIs. Whether this is done voluntarily (by offering a product for distribution via API) or involuntarily (by providing regulatory mandated APIs), it is in the interest of your bank to integrate certain suppliers into your process so as to ensure a stable and smooth customer journey. In addition, the broad technical scope of open banking requires most banks to create and manage new supplier relations and align technical delivery. We recommend building a CtB team that understands the business and is able to manage multiple suppliers smoothly at the same time.

Version upgrades

The last part is a tricky one as it is difficult to forecast the amount of capacity required. As mentioned earlier, open banking is constantly evolving. This means that new versions are published on a frequent basis. The regulation states that you must complete a major upgrade within six months after it has been announced, a minor one within three months. If you do not plan for that in your open banking CtB team, you will quickly face an ever-increasing backlog and potentially new issues with the regulatory authorities despite having passed the first few major milestones. Competitors might outpace you, causing your bank’s share of the fast-growing open banking ecosystem to dwindle. Therefore, you must make sure not only that you have dedicated resources that can deal with the constant evolution of open banking but also that they are flexible enough to adapt to changing tasks. As a starting point, the capacity required for past version upgrades should inform future capacity requirements on a yearly basis.

Team organisation

This brief insight shows that open banking does not stop with release 1 in production. It will not only need to stay alive, it is doomed to grow. So what team setup is best to manage open banking, and which business area should form the umbrella of this team? Without taking a specific look into your bank’s organisation, it is impossible to answer this question. Even if a business umbrella is determined, is a classic separation between RtB and CtB teams or a dedicated open banking team preferable? We suggest going with the dedicated open banking team because of the complexity of the solution and new skill sets that are required. It is often the case that the required skills are not readily available in the operations (RtB) team. In addition, combining the team into a vertical organisational unit can propel know-how transfer with the team while also providing flexibility in terms of capacity. Open banking will grow in scope and market size over the coming years, which means that additional know-how will need to be built up in-house. Separating the tasks into RtB and CtB as might have been the standard practice for other projects isn't necessarily the best option (just because it has always been like that or because project closing standards can be followed). It is highly unlikely that you can build up a dedicated team of people with a strict division of tasks between RtB and CtB in open banking. The complexity and the skills needed call for a dedicated team to cover whatever is necessary. We believe that creating a new vertical integration unit that incorporates both RtB and CtB tasks can cope best with these demands.

Recruiting a versatile open banking team with outstanding technical skills isn't easy. There has been a lack of expert personnel on the market due to the recent launch of open banking and PSD2 across Europe and the UK. It is difficult to predict how fast the resource market will grow compared with the overall market, but if it is anything similar to what we have seen this year, open banking resourcing will need to become a strategic management decision and not a short-term reaction to a short-term capacity constraint.

Summary

We believe that we have now addressed the most important aspects that your open banking organisation must cover. As the industry has just launched the new services, and each organisation features its own specification, it is a difficult task to give a detailed answer as to what is the best organisational approach for your bank. The most important point to keep in mind is the wide variety of tasks involved in open banking and the fast pace of change in the ecosystem. Whatever way of working your bank currently has, do not limit the decision by deriving it solely from the current setup. A different setup with a dedicated team might be a better approach, even if it goes against the current norm in your organisation.

Open banking is just the beginning of the API-led financial services economy. Unlike many other projects and initiatives in the financial industry, open banking will not just disappear or be handed over to Business as Usual (BAU) after it has been launched. We hope that this series of articles has provided you with insights and details of best practice experience that we have gained in our open banking projects. Please get in touch with us if you are dealing with similar challenges or if you are interested in further information.

Would you like to talk to someone who can share hands-on experience in open banking? You can reach us directly using the contact details below.