After The Security and Privacy Tale of Three Smart Cities, the next puzzle piece concerns how CyberSec4Europe is addressing some of the security aspects of Open Banking.

Sharing Fraud Information

Today financial fraud is global. As bank strategies are focused on digitalising critical processes like opening a bank account or adding a transfer beneficiary to a bank account, it has become very easy for hackers to carry out fraudulent transactions from their living rooms within a short period of time and without their physical identity being fully exposed. Moreover, they can attack several banks without having to change their mode of operation, given that today banks don’t share information on frauds that have been effective and any associated data. Finally, with new applications of technologies like Instant Payment which provide bank users with real time money transfer services, it is even more difficult to fight fraud, as banks don’t have any time delay in which to carry out recalls in case of fraudulent transactions.

This demonstrator is the first step in the implementation of a trust network aimed at providing banks with a channel to share and exchange critical information about effective frauds, leveraging the latest online open banking services. First, by making such sharing possible, banks should be able to improve their ability to detect and react in real time to cases of fraud. For example, if a bank which had detected a transfer fraud were able to share with other banks the information about the IBAN implied in the transfer, these banks could take this information into account as soon as possible to prevent the fraudster from using this IBAN to carry out other fraudulent transactions.

The security aspects of PSD2, including the introduction of strong customer authentication (SCA), help the fight against fraud, leveraging identity theft techniques. Nonetheless, the majority of financial losses are due to successful modes of fraud operations for which user authentication is inadequate.

• The Demonstrator Set Up

For the first release of the demonstrator we are focussing on two scenarios associated with sharing fraud information.

Means of Payment Fraud: A customer interacts with her bank to establish an account which then provides ready access to cash and credit. Ironically perhaps, the customer is either the individual or representative of a criminal organisation intent on defrauding as many financial institutions as possible in a number of different ways. From the perspective of the bank or merchant, this is a bona fide customer, who has opened an account and is carrying out everyday transactions, only to get unmasked as a fraudster after the fraud is detected.

The bank is represented by a fraud expert who carries out due diligence on the account request through KYC (know your customer) procedures and provides the mechanisms for the customer to get access to cash and credit facilities. The banks or financial institutions being targeted are the ones to incur financial loss and loss of brand credibility. Typically, if a fraudster is successful with one bank or financial institution, he or she will move on to attack another.

Credit Renegotiation Broker Fraud: A fraudster is an individual or representative of a criminal organisation (and who, depending on their mode of operation, could also be another bank customer) who interacts with an unsuspecting bank customer in order to get the necessary credentials/documents to defraud the customer.

The customer who is the target of the fraud has a pre-existing arrangement with a credit company which is a passive recipient of credit facility requests unaware that they are fraudulent (because they don’t have the means to be informed). In addition, a bank also acts as the recipient of ill-gotten monies from the fraudster that the customer eventually seeks reimbursement from.

The demonstrator will be extended in the next phase of the project with more scenarios, intervention/detection mechanisms and potentially additional actors.

An Open Banking API Architecture

This set of use cases involves six different scenarios associated with attacks on a bank’s internal systems by a hacker or a malicious user who tries:

• to gain illegal access to the system;
• to tamper with customer data;
• to gain unauthorised access to information;
• to access customer data through API vulnerabilities;
• to access customer data by injecting code into a client-side application;
• to compromise a service with access to an internal API.

The scenarios described are plausible for all European banks and third-party service providers that have an economic interest in the network architecture. In particular, banks are able to easily connect other APIs in the market in order to extend their service offerings by introducing native plug-and-play FinTech solutions. Through embracing the Open Banking API economy, banks are able to further enhance and transform current offerings – increasing their appeal to existing and prospective customers alike.  However, Open Banking APIs can also create a threat for banks, as they enable Fintech firms to tap into a bank’s financial data. For example, a Fintech startup may decide to use a bank’s “Customer Data API” in order to build a mobile application where customers budget their finances, manage their debt, and get real-time investment and financial advice through chat. The majority of traditional banks do not offer such debt and real time finance management services. This means that by opening up their API, the bank has enabled the Fintech to fulfil this existing gap and drive a wedge between the bank and the customer.

• The Demonstrator Set Up

In the demonstrator we show how the Open Banking API Architecture platform can overcome the security issues associated with:

• an unauthorised user
• unauthorised access
• unauthorised use
• a man-in-the-middle attack
• the misuse of a user interface
• privilege escalation
• integrity/confidentiality compromise
• API misuse.

In each of the six scenarios mentioned earlier, the attacker is first able to get access to a bank’s system or exploit some vulnerabilities against the platform non-compliant with security requirements; we then show how the attacker can be blocked by the application of appropriate countermeasures.

David Goodman, TDL