It never fails. A new transaction channel opens, and we start seeing fraud take hold and grow there. It’s already happened with mobile; as the channel has grown, so has the incidence of fraud. According to RSA’s Quarterly Fraud Report, mobile browser and mobile web applications accounted for 56 percent of global transactions among RSA customers, and the incidence of mobile fraud reached 71 percent. Extending that trend into the future, it’s reasonable to anticipate that as third-party channels enabled by the revised (EU) Payment Services Directive (PSD2) take a growing share of banking transactions, we’ll see fraud increasing in that channel as well.
PSD2 includes four technical requirements aimed at strengthening the security capabilities of banks that share data with third-party providers in accordance with the directive. These Regulatory Technical Standards (RTS) require strong authentication for transactions, anti-malware capabilities and secure APIs. Here’s a summary of the requirements and how technology can help meet them. (Note: All the requirements apply to banks; some may also apply to third-party providers, depending on what role the third party plays.)
1. Strong Customer Authentication
Achieving strong customer authentication means going beyond traditional username/password authentication to authenticate based on additional factors such as biometric authentication (fingerprint or facial recognition, for example), mobile push-to-approve, SMS, OTP and tokens. To address PSD2’s SCA requirements, a bank will need an authentication solution that supports a variety of strong authenticators like these, and also performs transactional risk analysis by evaluating user behavior, device characteristics, geo-location and other transaction characteristics to determine the degree of risk the transaction poses.
2. Anti-Malware Capabilities
Banks are frequent targets of malware-based cybercrime attacks that are aimed at gaining access to user credentials, with the ultimate goal of using those credentials to commit fraud. PSD2’s anti-malware requirement aims to reduce the risk of fraud associated with stolen or compromised credentials. Banks can address this requirement by deploying threat detection solutions specifically designed to identify activity showing signs of being contaminated by malware. This malicious behavior is the case in attacks such as account takeover, password guessing, or man-in-the-middle attacks.
3. Secure APIs
Open banking requires using open APIs to connect banks with third-party providers, which can potentially open up a new attack vector. This is the area where banks will have to do the most work to prepare for PSD2. They’ll need to create new API infrastructures expressly architected for security. They’ll also need to implement risk management solutions that recognize the risks open APIs introduce and facilitate creating an effective control framework to address those risks.
4. Risk Management
There are many risks that will be introduced by PSD2 – both operational and third party risks – and those risks must be managed effectively. Banks and TPPs will experience significant growth in the volume of their B2B network connections and traffic due to the API requirements of PSD2 and a growth in exposure of core banking functions thus driving up enterprise risk. In addition, by mandating banks to do business with third parties, they will soon face the challenge of how to aggregate and understand risk from potentially dozens to hundreds of TPPs. As a result, a solid governance, risk and compliance (GRC) framework will be required to manage the requirements and risks introduced by PSD2.
# # #
If you’re a bank or third-party provider that is required to implement the RTS defined by PSD2, you have until September 2019 to do it. Learn more about the technical requirements and how to meet them in the KuppingerCole white paper “Preparing for PSD2 technical requirements using RSA solutions.”