There are always regulatory changes and challenges in the financial sector; rapid changes in technology, social habits and political environments all affect the ways in which we bank, how we manage our money and the way in which banking services are provided. One of these is PSD2.
What is PSD2 and who will it affect?
PSD2, at a European level, is the second “Payment Services Directive” and it defines a way of handling and managing payment and banking services that introduces some fundamental changes to the financial sector – notably around the way larger banks and financial services providers need to allow access to systems and information, and the creating of new types of Fintech organisations that can access account information (Account Information Service providers, AISPs) and Payment Initiation Service Providers, PISPs).
More widely “Open Banking” – a big deal in the UK and elsewhere in the world – is driven by competition and markets rules. This also aims to force larger banks to make room for newer, innovative service providers. In many cases through the enforced creation of API (Application Programme Interfaces) into existing banking systems.
APIs are a big change
If you consider where banking IT has come from; a relatively short time ago banks had IT systems that were operated by their internal users and/or employees. Then came the web, ecommerce and online banking and now it is far more common for people (i.e. customers) to carry out banking transactions themselves through a web site and/or a smartphone app.
This mean that transactions, account lookups, queries and payment instructions went from operating at human-to-human speeds and volumes (governed by the number of employees, the availability of branches and the frequency of people calling in); to a world where they operated at human-to-machine speed where people conduct on-line banking and initiate transactions themselves at the speed they want and as often as they want.
The move to greater access by APIs from third party systems under PSD2 could be another order of magnitude change in volumes, speed, frequency and throughput. For example, you might access your online banking every day or maybe a few times a week to check balances and payments. It is entirely conceivable that a start-up Fintech will create a service that means they access your account every hour to check payment statuses, monitor for fraud or keep an eye on what your kids are doing, for example.
This type of service (an account information service) might lead to your bank having to deal not with one inquiry/transaction a month, or one a day, but one every hour or more! It also means a considerably higher volume of on-line access, instructions and queries to conduct security monitoring across.
PSD2 and Open Banking APIs: Customers at arms-length
The other challenge banks and other API providers may face is that at present they have a direct relationship with the customer making the request. So authentication, fraud detection, cross-selling of services and products, alerting to changes to terms etc all happen as a direct conversation with the customer; where intermediaries are involved this interaction will be less direct.
For security teams this may mean that although there will be a set of controls around the way APIs interact and the access/authentication processes; there may be security (or fraud) indicators that are less hard to utilise in a machine-to-machine world.
Suppose an organisation or service sprang up that carried out account/transaction checks every hour; or moved money around between accounts/savings continuously to maximise interest rates … these types of processes would mean that patterns of user behaviour, or login locations, or sources of connections become much less useful as indicators as it would be the location or origin of the service provider not the user, and the accesses could be continuous rather than at the set/usual times that a user might conduct on-line banking.
Past indicators of fraud, such as accesses or transactions from unusual locations or at unusual times, might now be obscured as the customer worked through an intermediary.
Aggregation of users under Open Banking and PSD2 APIs
One challenge with the use of APIs is that the ability to enforce policy or limit/contain threats at a per user level will be harder for banks to process – risking the shutting off of a large number of users if a service is thought to be compromised or needing to work through a third party if a user has fallen under suspicion.
If an on-line banking user account, access device or card is currently reported stolen or known/suspected to have been compromised it is a simple process at present for the bank to put a stop on any further activity.
Where an API service falls under suspicion of being compromised then taking action to stop transactions could affect a large number of their users (and the banks customers) and hence attract a degree of regulatory attention (the regulations don’t allow blocking APIs accessing without good reason). If a user is felt to be at risk, then the bank may be able to stop activity from them via an API, but it might also need to communicate this to the API provider for them to convey to their customer (the individual) or to ensure that other banking services they are connecting to are protected.
Security monitoring and automation
Aside from the business and customer interaction changes that PSD2 and Open Banking will involve, there will be some implications for the way in which security monitoring and threat detection systems operate in this new environment.
- The need to bring application and transaction logs into the security monitoring field of vision will be vital.
In the past, security oversight often focused at the infrastructure layer and at web front ends; however with API based access there is a good chance that security information and intelligence may be more embedded in the application/transaction logs than in the past. The challenge here of course is that while there are often core banking platforms in use there are also often other applications involved and theses may be customer specific or highly customised; so deploying a monitoring solution to ingest and process these will mean having the flexibility to handle and configure ad hoc or bespoke flows of data and activity information.
- Much higher volumes of security information will need to be handled
Aside from the simplistic addition of application or transaction logs and activity mentioned above, the addition of an API to the online banking access model means additional data volumes. However, the big change, as we highlighted, is that humans tend to interact with systems in a fairly measured and predictable way. You might check your balance on Monday morning on the way to work, and then again Friday afternoon before the weekend. You might move money around or make payments 3-4 times a month.
An AISP or PISP acting on your behalf to monitor your account, provided a real time financial dashboard, or shifting money between spending accounts and interest bearing accounts may access the online bank interface several times a day, maybe even several times an hour.
Payments that you normally make on a monthly basis via direct debit might move to being charged daily, services you might currently subscribe to might charge AND BILL by the minute and in real-time (why would they wait till the end of the month to bill you?).
So this means a much higher volume of data, richer feeds and higher transaction rates, than in the past. Scalability, flexibility and licensing models that allow these high volumes to be handled, processed and stored will be key.
- Collecting, monitoring, analysing data and identifying issues is going to need to be real-time, or at least very low latency.
The speed with which a problem could become serious in an API connected ecosystem of banks and service providers could be alarming. Although regulators, service contracts or consumer protection laws might define who carries responsibility and liability for fraud of security problems, the speed of risk propagation might make this nugatory – if a small organisation ends up carrying liability for a massive amount of fraud as a result of a security breach, they could be come insolvent and then where would there be redress from?
The activity on the system is working at machine rather than human speed Any intelligence gathering, analysis, detection, triage, containment and response will ALSO need to operate at machine speed. Flagging up lists of problems, issues, threats or potential attacks for a human to work through one-by-one will not suffice.
See our blog on monitoring and context in cyber security.
- Automation will be vital in data/intelligence gathering, contextualising, verifying and responding to security threats.
This follows on from the need for real-time processing – systems are going to need to be set up with sufficient analytical ability to take the various streams of data and operating contexts and both generate and verify security threats themselves. It is not going to be sufficient to flag a list of “potential” issues. This list could be 1000 entries long, and only eight of those might be real. It is going to stretch the areas of security analytics, user behavioural, machine learning and anomaly detection to identify problems, rule out false positives and gather sufficient information so that security operators are presented with a confirmed problem and the background data to make a decision.
In fact for all cases where the risk/impact of responding or containing a threat is lower than the risk of not acting, the system needs to be empowered to achieve a level of certainty in the outputs it is allowed to verify and respond to an attack immediately. This can be done safely, using the context and workflows that human teams would also follow to reach the same decision – and should ensure that where an error is made (for example, in disabling an account or blocking a transaction flow) that the organisation can easily step back in to undo or redo the operation that was suspect (but turned out to be genuine).
See our blog post here on automation.
Implications of PSD2 and Open banking on Cyber Security Operations
Changes to the way banks operate are inevitable under the Open Banking and PSD2 regimes. This will mean allowing third party systems access to data and systems that were previously only allowed to entities (staff and customers) over which the banks had some connection and control.
The effects on monitoring security operations, threat detection and analytics will be marked by a massive need to increase speed of detection and response in a scalable way; allowing machines to work at machine speeds means security processes will need to operate similarly fast.
Relying on security analysts to take on the volume of machine generated alerts and still respond at an acceptable speed in this interconnected banking and service provider system environment will become less tenable and increase the need for investment in AI, machine learning and automation not just in detecting issues; but throughout the incident lifecycle.
To discover the cyber security implications of PSD2, go to our PSD2 web page.
You can also download our Infographic:
Products
Solutions by Industry
Learning & Resources
About Huntsman
