When I am asked about open banking there is normally a curious dichotomy to be observed: On the one hand, the UK open banking initiative, which is agreed to be the leader in the field, has achieved relatively little. And yet on the other hand, ‘open banking’ is ‘going viral’ globally.
Which then leads to the realisation that there is not one answer to the question “what is open banking?”, there are at least three.
Looked at from the ASPSP’s perspective there are at least three different layers, all demanding differing approaches:
The pure compliance layer: Under PSD2, and therefore the CMA Order, ASPSPs are obliged to permit regulated TPPs access to the customer’s data, if the customer grants his consent, without challenge, without making a charge, and without being able to require any contractual agreement (even SLAs, rules to deal with exceptions, liabilities etc).
ASPSP’s own offering to its own ‘stable’ of TPPs to enhance the experience for the bank’s consumers: Poster boys for this approach include Nordea and DBS. This reuses some of the same functionality as the first layer but takes a fundamentally different approach, more akin to AOL’s initial ‘walled garden’ response to the internet. This is where most of the open banking action is just now. Even though some would argue the underlying philosophy of this is a contradiction of true open banking.
Full data sharing ecosystem: Although the future is obviously not totally clear, it is likely that the market will evolve to expand beyond banking to ‘open everything’, and that the value of information will be the key driver, rather than the ability to initiate payments. The key immediate driver for banks in the near term is a focus on becoming a TPP accessing other’s data (e.g. HSBC and Citi). Ultimately it seems to be driving banks from a model that seeks to force-feed its products to customers to be more an offeror of quasi-price comparison / brokerage services. Also, given that the TPP has to be totally responsible for its use of the data once it has left the control of the ASPSP there needs to be more robust controls than are currently contemplated within PSD2. Maybe something scheme-like.
Although these layers blend together and overlap they have quite different conceptual underpinnings and they lead to different outcomes. So, on the one hand they probably need to be managed separately within the bank to avoid confusion, the solutions should be devised to apply reusable modules, since 80% of the underlying functionality is the same.
To explore each of these in a bit more detail.
1. The pure compliance layer: Under PSD2, and therefore the CMA Order, ASPSPs are obliged to permit regulated TPPs access to the customer’s data, if the customer grants his consent, without challenge, without making a charge, and without being able to require any contractual agreement (even SLAs, rules to deal with exceptions etc).
Progress here has been slow. The live APIs are relatively limited (e.g. the payments initiation is a ‘fire and forget’ payment) with little of the functionality required to oust cards.
Further progress has stalled because of the unfortunate way the authorities have chosen to go ever deeper into strong customer authentication and secure communication. Thus it is hard for banks to justify any investment in building the ‘dedicated interface’ while there is little clarity what is required. For example, the EBA’s Opinion and Guidelines appears to have given many banks more grounds to wait to see the definitive outcome before investing. So proving Ronald Reagan’s adage true that the most terrifying nine words in the English language are: “I’m from the government and I’m here to help.”
Further from an IT vendor’s perspective it is hard to justify investment, because:
It is unclear what is required for the dedicated interface as discussed above;
Because the solution is dictated by regulation the solutions differ between countries, even within Europe; and
Because of the way PSD2 has been specified (no ability to charge, no contract etc) there is no commercial upside to the compliance service. So it is hard to make a case to build a commercial IT solution to support this layer.
Hence progress here has pretty much stalled and the real activity is taking place in the second layer.
2. ASPSP’s own offering to its own ‘stable’ of TPPs to enhance the experience for the bank’s consumers: Poster boys for this approach include Nordea and DBS. This reuses some of the same functionality as the first layer but takes a fundamentally different approach, more akin to AOL’s initial ‘walled garden’ response to the internet. This is where most of the open banking action is just now. Even though some would argue the underlying philosophy of this is a contradiction of true open banking.
In contrast to layer one, layer two is much easier to move ahead on and use to create value for a bank. Furthermore, because it is driven more by commercial considerations it is possible to roll out the solution internationally. This makes it easier to cost justify for a bank to build, and for IT vendors to support. Hence rather than the very few APIs that have been produced by the standards bodies, these private initiatives have implemented APIs in the hundreds, which are more functional, quickly deployed, and rapidly amended for customer feedback. Some banks may even be hoping that by producing such a functional service for customers in this layer the regulators will just declare victory and move onto pastures new. Especially as layer one grinds to a halt.
However, it is unlikely that this approach will persist in the long term. In the same way that AOL and others that felt they had special relationships with customers’ ‘eyeballs’ got overtaken by a more ecosystem driven approach.
There is a reason for the adage that “If you want to go fast go alone; if you want to go far go together”. Very quickly the confusion of solutions and bilateral relationships will become hard to sustain and banks and TPPs will want to establish some degree of commonality and stable multilateral solutions. This will likely include features such as:
Being similar to the Internet model. That is, with simple, slick linkages at the centre with functionality at the nodes, and
With some sort of scheme style rules to create predictability and certainty between the parties. Most notably to address the risk of data loss in a systematic way.
3. Full data sharing ecosystem: Although the future is obviously not totally clear, it is likely that the market will evolve to expand beyond banking to ‘open everything’, and that the value of information will be the key driver, rather than the ability to initiate payments. The key immediate driver for banks in the near term is a focus on becoming a TPP accessing other’s data (e.g. HSBC and Citi). Ultimately it seems to be driving banks from a model that seeks to force-feed its products to customers to be more an offeror of quasi-price comparison / brokerage services. Also, given that the TPP has to be totally responsible for its use of the data once it has left the control of the ASPSP there needs to be more robust controls than are currently contemplated within PSD2. Maybe something scheme-like.
Straws in the wind that suggest this is the direction of travel include:
The move towards data sharing as the key driver rather than payments: In Europe, the original driver of the Payments Services Directive has stalled and most of the action that is taking place is in the area of data sharing. In the UK there is talking of switching the focus from open banking to ‘open everything’ (pensions, investments, energy, insurance etc). In Australia the focus is more on data sharing than payments as the first phase.
The perimeter of service providers is too dynamic to be policed in the first instance by the regulators: In Europe the basis of PSD2 is that only entities regulated under PSD2 should be able to engage in TPP activities. Only they can get on the regulatory registers and obtain digital certificates. Further, Professional indemnity Insurance (PII) only covers regulated activities, and even then, there is a lack of rigour in the approach, especially as relates to data sharing, that means that the PII is simultaneously an expensive barrier to entry for TPPs and yet unlikely to reliably protect the consumer.
This paradigm has been tested to destruction, and it is not sustainable. Even within banking there are parties that need access to the data but are not to be regulated:
Fourth parties, like Yodlee, that obtain the data and then pass it onto customer-facing TPPs;
Merchants, accounts and lawyers etc that undertake data access incidentally rather than by way of business;
Businesses that cannot be regulated just because of what they are, like NSI.
Further data sharing beyond the confines of PSD2 is not regulated by PSD2. Even arguably information that is not account information, like contact details, age, account characteristics. Even the definition of ‘payments accounts accessible online’ is proving more complex and unhelpful than might be hoped.
Other geographies are therefore immediately moving beyond the artificial European construct that banks should not be able to require some reasonable contract, some reimbursement of costs, and related, and some ability to monitor and control access.
Once this is acknowledged that this is required there is an immediate logical straight line that suggests that a scheme with standardised contracts, and able to undertake front line supervision of participants is a more logical model than suggesting national competent authorities should police TPPs. Hence, we are seeing parties like Mastercard making proposals in this area.
Especially since banks are likely to become TPPs, since this is how they will monetise the data sharing economy. Hence for example Citibank suggesting recently it will be a TPP in the UK using OBIE standards, but without any apparent undertaking to provide ASPSP access to its own accounts.
This will create issues for banks in that it will have to shift from a focus on selling its own products and services to becoming more of a marketplace or brokerage providing best execution, even if products sold are not its own.
Also, the banks will need to create a separate physical or virtual database of their customer’s data that is accessible for TPP purposes. This would also need to be able to purge or put beyond use data if and when the customer consent is revoked.
So what?
Assuming you agree with this analysis the obvious nagging question is, "so what?" Well to begin with.
For banks
These three different layers will need separate teams working on the three different layers to ensure they are separate and focused.
However, the bank will want a solution that provides the underlying framework for all three layers in a modular form since so much of the functionality overlaps and should be provided consistently.
For IT vendors
Similarly IT vendors need to provide a solution that works across all three layers for the same reason.
Also, slightly counter-intuitively they should be targeting layer 2 ahead of the pure compliance layer, since that is where the short term action is. Albeit with a vision to build a solution that encompasses layers 2 and 3.
For TPPs
Since the action is more in layer 2 at this stage, TPPs should spend more time building relationships with banks than working just on the compliance standards in layer one. Especially since it is starting to look likely that evolution will go from layer two to layer three leaving. With layer one becoming an increasingly philosophically well-specified by experts, but increasingly practically unworkable solution, with little ability for customers to contribute to the debate and for pragmatic solutions to be testable in the market.
For authorities wanting to progress open banking and data sharing:
To avoid overly detailed regulation it is suggested that the authorities restrict themselves to laying down policy objectives and overseeing progress, but charge the industry with defining and implementing the changes required. This helps avoid the ‘moral hazard’ and impracticality of detailed rule setting.
In a follow up article I will include some more thoughts in this area with regard to potential solutions going forwards. In the meantime if you have any thoughts on this topic please do reach out on peter.davey@triari.co.uk, or +44 (0)7986 680 283.