Where are the likely “banana skins” for bank CROs from PSD2 and Open Banking?
In general, Chief Risk Officers (CROs) and Boards of Directors of traditional #banks probably lose a lot more sleep over the health of bank balance sheets rather than the security and agility of daily payments and accounts processes. A failure to control the quality of loans on the balance sheet is an existential risk for a credit institution. A failure to maintain depositor confidence, leading to a cataclysmic outflow of funds from the liabilities side of the balance sheet, is also an existential threat. While significant frauds, security failures and data privacy breaches may tarnish bank brands, slow business growth and lead to very large regulatory fines, these events have to be incredibly large and systemic to suddenly wipe out a bank’s equity or cause a loss of a banking license.
Although banks may have ultimately adopted progressive API Strategies over time, banks are being compelled by #PSD2 to adopt API-driven business objectives and processes against a fixed deadline. Without regulatory intervention, the timing of this change would have been commercially driven. In more normal circumstances, the Boards of these banks could have approved new API Strategies (covering API provision and consumption) with a defined appetite for risk. This is the level of risk that a bank is willing to accept in order to deliver these business objectives. It will be important that the mandatory nature of PSD2 does not inhibit banks from carrying out these important disciplines. Even a “comply only” API business strategy prompted by PSD2 does not mean that bank Boards are not ultimately responsible for the risk profile of these business activities.
To try to avoid adverse outcomes, bank management and Boards of Directors spend much time defining their appetite for risk. To inform the process of defining risk appetite, banks invest much time and effort in developing risk models. Many of these risk models are devised and prescribed from the “top down” by Regulators and prescribed to a class of banks, in order to compare risk profiles. Risk models are also devised and implemented from the “top down” by #CRO and specialist risk management staff. For example, banks model the adequacy of capital levels and loan loss provisions in adverse economic conditions (often under regulatory supervision, such as the recent Stress Tests conducted by the European Banking Authority). These models help inform CRO responses – can and should risks be avoided, reduced, shared or accepted?
[linkedinbadge URL=”https://www.linkedin.com/in/paulrohan” connections=”off” mode=”icon” liname=”Paul Rohan”] , the author of this post, is also author of “PSD2 in Plain English”.
for Non-Specialists) (Volume 1)
PSD2 and #Open Banking is not a matter of a faster growth rate or a diversification into new market segments, using established business processes and risk models. In broad terms, PSD2 is extending and blurring the boundaries of a bank. With PSD2 and Open Banking, there are now new risks to a bank’s risk profile outside of contractual arrangements that the bank has chosen to enter. It could be difficult for bank CROs to fully understand and fully embrace the lessons from risk management problems inside PSD2’s “Third Party Providers (TPPs)”.
Does a bank’s CRO have a big blind spot in this new Open Banking environment? As the layer of overlay Payment Initiation and Account Information services grows into an ecosystem, the capability of the CRO to quickly identify where a fraud could happen or how a fraud was executed will fall. The possible points of weakness increase as more and more payment initiation is captured by the risk management and security of TPPs. There may be many TPPs for a certain type of payment or a certain device or security protocol that is breached across many TPPs. Calls from puzzled customers to a bank’s Call Centres will have many more scenarios to plan for and many more scenarios to try to understand. Call Centres will ideally have to know exactly the TPPs, current and lapsed, that a customer has granted PSD2 access to. Call Centres and Client Education will probably have to prepare and plan for the emergence of imposter TPPs. The normal patterns of API calls on a bank’s payments hub will have to be tracked as accurately as the normal pattern of customer instructions through proprietary channels,
The initial risk model prepared for PSD2 and Open Banking will have to come from the “bottom up”. Staff managing business units with expert knowledge of a certain set of products and processes can model their risk profiles from the “bottom up”. These models are used across a range of risks to help banks identify and manage the risks that they are running. A very common model is a “Risk Matrix”. It is a simple mechanism to increase visibility of risks and assist management decision making. The severity of an event could be classified as Catastrophic, Critical, Marginal or Negligible. The probability of an event occurring might be categorised as ‘Certain’, ‘Likely’, ‘Possible’, ‘Unlikely’ or ‘Rare’. It is likely that the technical function that physically manages the Private, Partner and Public APIs will be documenting new risks from newly published APIs on their unit Risk Matrix. The commercial function or functions that have line of business responsibility for API Monetisation and PSD2 compliance will probably be documenting different PSD2 risks a different Risk Matrix from a commercial perspective.
The initial risk model will have to correctly identify and maintain the correct number of Payment Accounts that must be exposed by law. Banks will need to ensure that new controls are designed and effectively implemented so that TPP Permissions can be revoked by End Users who hold accounts at the bank. API Related Complaints by End Users or by API Developers will need to be monitored as potential indicators of risk. Managing data and privacy (both of customers and API Developers) appropriately in an Open Banking environment is a risk. If an API is temporarily or permanently withdrawn, a bank will need to understand the implications of that action. When significant actions or first-time processes are triggered by the end users, banks will need to be sure that Out of Band Challenges will go to End Users. API Permissions with an expiry date will need to expire on the time limit. If there is a dispute over a potentially unauthorised payment through a Payment Initiation Service, banks will need to be sure that PSD2 is being observed and an immediate refund is triggered. In the early days after PSD2, there is no “typical” or “average” number of risk events to guide a bank’s risk responses or risk appetites. Banks will also be required under PSD2 to share information on security threats. There will be guidelines for managing security incidents and the EBA will set guidelines on how to handle complaints.
In the early stages of Open Banking, volumes will be low. A key driver of the “severity” weighting that bank staff will use on a “Bottom Up” Risk Matrix will be both the volume and the value of the transactions that are traveling through this process. Relative to the volumes that currently travel through a bank’s proprietary channels and the enormous values of payments through a bank’s Treasury function, the initial Open Banking traffic is likely to be initially classified as “Marginal”. CROs may not see Amazon, Apple, Google, Facebook and Microsoft appear in the Overlay layer of TPPs in the first few months of the PSD2 and Open Banking regime. However, it is probably a mistake to assume that all “Fintechs” are small and undercapitalised, thus unlikely to trouble a bank’s infrastructure with a surge of volume. “Silicon Valley” TPPs will have pan-EU ambitions and have potentially large appetites for API consumption. Crucially, EU banks could find that 80% of their installed base of customers already trust and actively use services from these giants.
We can reasonably speculate that the crooks and fraudsters that exploit opportunities in digital services could have their own “PSD2 projects”. What sort of new attack vectors for fraudsters could exist in this new, more complex environment? Fraudsters can read the new PSD2 legislation just as well as anyone else. The fraudster knows that a bank has only one working day after a disputed payment to refund any unauthorised payment transactions generated by a TPP. Fraudsters will know that banks will have to deal with potential payment reversals within the TPP process while an impatient customer has launched a fresh effort at the same payment through a traditional channel. eCommerce or Mobile Commerce transactions that historically only appeared as Card transactions will start to appear as Faster Payment Scheme Credit Transfers, disrupting and confusing customer payment profiles held by banks. Fraudsters could start to watch for authentication and control differences between TPP processes and traditional processes, building up a trusted profile for subsequent exploitation on the other process. Fraudsters will know that sensitive personal or authentication data extracted from unsuspecting TPP customers could later be used in a bank’s proprietary channels without the account servicing bank being aware of the initial breach.
In crude conclusion, the initial risk profile of PSD2 and Open Banking looks quite benign compared to some of the existential risks that banks face every day. However, as PSD2 and Open Banking starts to gain market acceptance and volumes start to ramp up, the “banana skins” will come quite quickly. CROs and Bank Boards will have to recognise that a new business strategy like exposed APIs has to be rigorously scrutinised for risk, whether this new business strategy is enforced by an EU regulation or not. Banks will have to prepare for the new PSD2 and Open Banking regime without any tested and mature risk models. The blurring boundaries of the organisation make a “top-down” identification of material PSD2 risks a difficult challenge for the CRO. Risks related to PSD2 and Open Banking will not be confined to one business unit, making the “bottom up” risk profile more blurred. At an industry level, there will be a period of time before a “sensitivity level” is established for the risk profile of Open Banking processes. The addition of 5% of a bank’s total payments volumes through TPPs in immature processes may be a “marginal” change in payments volumes but it probably does not represent a marginal change in the bank’s overall risk profile. The structure of PSD2 means that Silicon Valley giants could arrive with very large volumes and effectively unannounced, without having any prior relationship with the API publishing bank. Fraudsters will know that the addition of new overlay services managed by TPPs is a radical change in business model and is completely different to the incremental addition a new proprietary bank channel (such as tablet, mobile or kiosk) using the same proven customer profile and control processes.
In crude conclusion, the primary risk control for banks in this environment can only be a risk-aware culture. Bank management will have to seize growth opportunities from APIs while managing risk, just as in all other processes. The immaturity of risk classification models, industry norms and fraud detection models will mean that bank management will have to approach this arena from “first principles”. As API volumes grow, clear and active communication within banks and within industry bodies about the various “banana skins” will be crucial. #Fintech innovators seeking to build partnership relationships with banks in the Open Banking era should also welcome tough questions from banks about their risk control capabilities. If a bank is asking tough questions and paying good attention to likely risks in the TPP overlay layer, that bank is far more likely to be serious about building an ecosystem out of its payment
[linkedinbadge URL=”https://www.linkedin.com/in/paulrohan” connections=”off” mode=”icon” liname=”Paul Rohan”] , the author of this post, is also author of “PSD2 in Plain English”.
for Non-Specialists) (Volume 1)
Reply