Will decentralised Consent Management drive bank balance sheet growth after PSD2 and GDPR?

Platform ecosystems have the potential to change how all services are delivered, not just banking services. The orchestration of large numbers of application developers by platform owners could mean that an excellent service proposition offered by an isolated provider outside the relevant ecosystem becomes irrelevant.

If this radical change also happens to banking services, how will banks still capture the traditional sources of profitability in banking? The main source of profitability in banking has traditionally been net interest income (simply, loan interest income minus the interest paid on deposits). The market allows banks to earn this net interest income because of the risk-taking role of banks’ balance sheets. As Credit Institutions, banks carry shareholders’ equity on their balance sheets to act as a buffer, which absorbs losses when market conditions become adverse.  If borrowers default on their loan agreements (simply, this is credit risk), depositors still get their funds returned on schedule and the shareholders take the losses. Banks also perform a "maturity transformation process". Even though deposits can be funding loans with an average maturity of 2 years, depositors can get their money back as agreed on shorter maturities (simply, this is liquidity risk). 

The role of Credit Institutions is to funnel this mobility of funds and this has been their role for a very long time. The opportunity arises because “older and more highly developed areas frequently accumulate a plethora of funds which should be made available for use in other communities”, as described by Chapman and Westerfield’s “Branch Banking”, published in 1942. In short, the money deposited by Retirees in banks has been used to fund loans to Students for a very long time. In very crude terms, the Retirees get 3% on deposits and the Student loans cost 8%, because if one student doesn’t pay back any of his or her loan, 20 new Students at a 5% margin are needed to cover the 100% loss from one defaulting Student.

Service providers examining the growth and potential of platform ecosystems should see new opportunities to reach more Retirees and more Students – and to surface new demand for new services in those market niches in an emerging “long tail”.  

How will this new Open Banking environment reduce the industry’s costs of reaching these two particular niches (Retirees and Students) in an emerging “long tail”?

The open, networked and digitised environment has the potential to democratise the tools of production for assessing business opportunities in those niche segments.  The availability of professionally monitored and quality assured Open Banking data on the cash surpluses of Retirees and the cash shortfalls of Students will also swell a thousand-fold the number of informed service providers who can serve those niches. The cost of reaching these niches is reduced by democratising distribution. As more and more Retirees and Students manage their activities through mobile devices connected to the Cloud, the availability of that data (through APIs, with the consent of Retirees and the consent of Students) makes it cheaper to reach more of them. That, in turn, will translate into more consumption, effectively raising the number of successful services for Retirees and Students. The new Open Banking environment can better connect supply and demand. More effective context-sensitive services will introduce Retirees to new types of savings and newly available savings products. More effective context-sensitive services will introduce Students to new types of loans and newly available loans. The effect of all this is for both Retirees and Students to lower the “search costs” of finding new “niche” content i.e. savings or loans that are informed by high quality cash flow data that is sensitive to their specific circumstances and specific market segment. Some of the search costs are non-monetary, such as wasted time, hassle, wrong turns and confusion. Other costs are financially measurable, such as saving or borrowing in the wrong way or on the wrong terms.

The progressive banks will not see PSD2 and Open Banking as a “zero sum game” being played out between banks and fintech, in a market that will remain the same size. A bank with platform strategies can capture new balance sheet growth opportunities with Retirees and Students without having to attempt to create products and services for them. Instead, non-bank business partners loosely connected to banks through data-sharing strategies can find and identify the niche opportunities. 

Banks and Non-Banks will want to share data about the respective lives, behaviours and needs of Retirees and Students, to earn new profits in the Retiree Services Ecosystem and the distinctively different Student Services Ecosystem. A bank aiming to build its balance sheet through engagement with both ecosystems will have distinctively different non-bank business partners, data exchanges, transaction pricing, marketing approaches and growth tactics within each ecosystem.

A Bank CEO is not likely to stop at just assembling two specialist teams to focus on the Retiree and Student segments. The Bank CEO could also assemble many small and specialist teams to focus on data sharing with distinctively different non-bank business partners in the "Customer Gets A Job Ecosystem", the "Customer Buys A Car Ecosystem", the "Customer Is A Frequent Leisure Traveller Ecosystem", the "Customer Changes Job and Relocates Ecosystem", the "Customer Purchases a Home Ecosystem", the "Customer Gets Married Ecosystem", the "Customer Becomes a Parent Ecosystem" and the "Customer Undertakes Major Home Renovations Ecosystem". Each of these ecosystems is likely to help grow the asset side of the bank’s balance sheet, in the form of new lending. The CEO could also assemble small and specialist teams to focus on data sharing with distinctively different non-bank business partners in the "Customer Finalises Plans To End Full Time Work Ecosystem", the "Customer’s Spouse Retires from Full Time Work Ecosystem", the "Customer Trades Down Home Size Ecosystem" and the "Customer Retires from Full Time Work Ecosystem". Each of these ecosystems is likely to help grow the liabilities side of the bank’s balance sheet, in the form of new deposits (and contain sales opportunities for pensions and investments).

The diversity of the ecosystems and the likely diversity of the non-bank business partners implies that a bank needs decentralised but controlled flexibility for partnering with non-bank business partners in the Open Banking era. A Bank CEO will want these small and specialist teams of bankers to be able to add, enhance and end data sharing partnerships with non-bank business partners without having to queue up at the central IT function for customised solutions to manage client consent and manage the scope and duration of the data sharing. 

A Bank CEO will also recognise that entering into a data-sharing partnership with a non-bank business partner is an implied endorsement to its customers of the business partner’s data processing standards. Whether the bank’s customer is paying a fee to the bank for the data-sharing process or paying a fee to the non-bank business partner, the bank aims to profit from this data-sharing activity. If the central IT team cannot provide “enterprise enablers” across multiple business lines and multiple business models that also ensures PSD2 and GDPR compliance, a Bank CEO cannot easily declare and mobilise a multi-segment strategy on Open Banking and partnering with non-banks. 

We can probably narrow down the required design of the Consent Management “enterprise enabler” by focusing narrowly on the Retiree Ecosystem and the Student Ecosystem. How can the bank’s specialist niche teams rapidly scale their data sharing with distinctively different non-bank partners in each of these ecosystems, while managing all aspects of client consent in accordance with GDPR? 

In simple terms, one small team of bankers will make commercial decisions on which data should flow out to non-bank partners and flow in from non-bank partners in the Retiree Ecosystem. Ongoing GDPR-compliant consent management capabilities are needed by this small and specialist Retiree Services team of bankers without reverting to customised support requests to the bank’s central IT functions.

Another small team of bankers will make commercial decisions on which data should flow out to non-bank partners and flow in from non-bank partners in the Student Ecosystem. Similarly, this team needs to be self-sufficient in ongoing GDPR-compliant consent management for Students.

While there will be some commonalities in the Retiree data flowing back and forth with the Student data, there will be data elements and customer treatment decisions that will be completely unique to each ecosystem.

How might GDPR impact on these small and specialist teams as they try to grow their business within their assigned ecosystem?

Article 4 (11) of GDPR says that “consent of the data subject means any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her”. This applies whether the data subject is a Retiree or a Student.  If there is to be extensive and diverse data-sharing with non-bank partners in distinctively different ecosystems, Bank CEOs will want enterprise enablers that are consistent across the bank. Banks will not want these small teams serving Retirees and Students to have very different policies or software to obtain these clear affirmative actions. Ideally, when the bank’s Internal Audit team comes to audit each of these teams, they should find consistent tools and processes obtaining these clear affirmative actions, notwithstanding the distinctively different non-bank business partners, data exchanges, transaction pricing, marketing approaches and growth tactics by each team.

Article 4 (11) of GDPR calls out the need for the client to be “informed”. The nature of the data-sharing should be explained in an intelligible and easily accessible form, using clear and plain language which does not contain unfair terms. The data subject (whether a Retiree or a Student) should be aware at least of the identity of the controller and the purposes for which the personal data will be processed. This information will inevitably have local elements and cannot be handled by centralised Terms and Conditions on data sharing.

Recital 32 of GDPR specifically recognises the validity of many commonly used methods of collecting consent in the form of an affirmative action e.g. “this could include ticking a box when visiting an internet website, choosing technical settings for information society services or another statement or conduct which clearly indicates in this context the data subject's acceptance of the proposed processing of his or her personal data”. This does not mean that a Bank CEO will be comfortable with complete decentralisation of consent management. A Bank CEO will want decentralised decision making about the scope and pricing of data sharing (both data-in and data-out) by the Retiree Ecosystem Team and the Students Ecosystem Team. However, scalable and enterprise-standard consent management tools and methods will be essential enablers of ecosystem-based competition by these teams.

Article 7(4) of GDPR requires that when assessing whether consent is freely given, utmost account must be taken of whether the performance of a contract is made conditional on the data subject consenting to processing activities that are not necessary for the performance of that contract. A Bank CEO will want consistent tools, detective controls and audit trails in place to ensure that this is being observed. The small team of bankers operating with non-bank partners in the Retiree Ecosystem will have to understand and have the tools to only seek consent for data sharing that is absolutely necessary to (say) provide a superior deposits experience; similarly, the small team of bankers operating with non-bank partners in the Student Ecosystem will have to understand and have the tools to only seek consent for data sharing that is absolutely necessary to (say) provide a superior Student Loans experience.

Article 6 (1) of GDPR says that data processing shall be lawful only if and to the extent that the data subject has given consent to the processing of his or her personal data for one or more specific purposes. As such, consent must be "specific". Banks will be entering into different data sharing with non-bank partners in the Retiree Ecosystem to the Student Ecosystem. There will be data elements and customer treatment decisions that will be completely unique to each ecosystem. The small teams put in place for each ecosystem cannot rely on a centralised set of “Consumer Terms and Conditions on Data Sharing Consent” to provide “blanket consent”, as blanket consent that does not specify the exact purpose of the processing will not be valid consent. Again, a Bank CEO will want consistent tools, detective controls and audit trails to ensure that these small, specialist teams in their respective ecosystems are not relying on “blanket consents”.

Article 7 (2) of GDPR requires that “the data subject's consent is given in the context of a written declaration which also concerns other matters, the request for consent shall be presented in a manner which is clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language”. In short, consent must not be wrapped up as part of a wider set of terms and conditions. If a Bank CEO assembles small and specialist teams to work within specific ecosystems, this reduces the risk of specific data-sharing initiatives being confused with other matters. However, in practical terms, this means that the small and specialist team of bankers that are data-sharing in the Student Ecosystem probably needs an effective enterprise capability to achieve a freely given, specific, informed and unambiguous indication of a Student’s data-sharing wishes as often as necessary under GDPR. 

Article 7 (1) of GDPR requires that “where processing is based on consent, the controller shall be able to demonstrate that the data subject has consented to processing of his or her personal data.” The bank’s Internal Audit team will want to find audit trails that can demonstrate the consents that are being achieved by each specialist team as necessary.

In crude conclusion, if the basis of competition moves from Product-versus-Product to Ecosystem-versus-Ecosystem, banks will have to completely change the business models that they have traditionally used to grow profitable balance sheets. This evolution to ecosystem-based competition will not just be confined segments such as Retirees and Students in a bank's Mass Market Consumer Banking business. Private Banking, Small Business Banking, Mid-Size Commercial Banking, Corporate Banking and International Banking teams will all have different variations of data sharing with different non-bank business partners in different ecosystems. Each banking line of business that is used to help construct a profitable balance sheet will probably fall into a different ecosystem. In each ecosystem, a bank will have distinctively different non-bank business partners. Some elements of the data-sharing will be common and consistent, as they will handle generic business processes. Other elements of the data-sharing will be unique to one ecosystem. While the “access to account” provisions of PSD2 seems to call out the Regulators preferred ecosystem-based market structure, the decentralised management of the “consent” provisions of GDPR may be the key enterprise enabler for a bank that wishes to scale smoothly and quickly. For a bank to start Open Banking, a relatively small number of people in a centralised project team had to immerse themselves in every line of the PSD2 legal text.  For a bank to scale Open Banking, a very large number of people placed permanently in small, specialised and decentralised teams may have to immerse themselves in every line of the GDPR legal text.