What is the role of SecDevOps in PSD2 compliance?
When it comes to online payments and credit card processing, retailers in the EU have been granted a reprieve. The European Union’s Revised Payment Services Directive, known in short as PSD2, extended its deadline for compliance to March 2021, leaving it up to retailers and banks to remain secure while legislation is left in limbo. And yet, a deadline extension does not mean companies can rest on their laurels. Consumers, governments, and developers expect banks and other services to be compliance-ready, ideally before the March 2021 deadline.
About the author
Subho Halder is the co-Founder and CTO at Appknox.
More importantly, hackers are aware of this gap in vulnerability. The PSD2 regulations are meant to increase competition and offer more consumer choice, however they also provide added security for vital banking details. Leaving this information undersecured provides a risky inroad for criminals. Let’s take a look at where we are today with these standards, and how companies involved with ecommerce can implement SecDevOps best practices into their PSD2 compliance.
1: The state of the APIs
A full 41% of EU banks are still not compliant with upcoming PSD2 standards, as of March 2019. While this is less than half, and the exact percentages vary by country, the main reason banks have dragged their feet remains the same: API testing.
First and foremost on the PSD2 compliance checklist is the need for banks to create APIs meant for transactional payment data. These APIs need to provide real-time access, fraud monitoring, multi-factor user authentication, and user behavioral analytics, among others. With all of these features, it’s not hard to see why some institutions have been slow to comply.
Yet these APIs will become the bedrock of digital financial transactions throughout the 2020s and beyond. Businesses and financial service providers will use the banks’ APIs to provide their own payment systems, perhaps creating their own APIs to fully utilize payment and behavior data.
In fact, banks themselves could also become Third Party Providers (TPPs), both creating and utilizing the APIs of other parties. The intended effect of this increased competition is to provide more consumer choice and thereby lower prices – a noble goal for any governing body looking out for its citizens.
On the surface, the PDS2 standards can, in fact, improve trust and security in digital financial transactions. Where the issue arises is in how banks create their APIs – and who ends up using them. And how.
2. Security against fraud – what consumers & institutions need to know
At the center of PDS2 are the APIs banks will create to provide services to TPPs. Security is paramount when banks create APIs – they have immense access to our most vital financial data. Any details that end up in the hands of untrustworthy characters are then subject to disaster.
As we noted, much of the discussion so far has centered around these bank APIs. Less focus has been placed on what TPPs and other institutions may end up doing with their own APIs. That is – what security regulations are in place for TPPs?
The truth is – very little. TPPs have both a strong advantage and a key flaw in regards to PDS2 that is one in the same.
For one thing, TPPs are not subject to the same strict regulations that banks have. This is one of the main drivers behind PDS2 – letting these TPPs provide payment options means more flexibility for consumers. They are also not subject to the same legacy IT infrastructures that many banks have.
Yet with this heightened mobility comes cost. If a TPP does not require as much rigidity to begin handling transactions, would that mean their security is less stringent as well? How can consumers know whether their new payment provider is handling their data security?
3: Defining best practices in PDS2
First, TPPs must be aware of the risks they’re facing. Fraud attacks, where malicious users create rings of fake accounts to exploit various benefits, rose 26% last year, even as more and more banks implement 2FA and other solutions to combat these crimes.
To an extent, TPPs can strengthen customer data security. They can share information among themselves, or with the banks whose APIs they use. TPPs with stronger security protocols have a better selling point for new customers – the exact sort of competition PDS2 is meant to stir.
At the same time, new challenges must be addressed before a breach occurs. For one thing, keeping track of which APIs are in use is paramount.
The API each bank releases will be checked constantly, as many TPPs will rely on it to provide services to their customers. Less rigorously-tested will be the APIs these third-party providers create themselves. As such, SecDevOps becomes the guardian between financial safety and hacker abuse.
There are a number of steps each party can take right now to ensure PSD2 safety later on. First, taking stock of which APIs are already in use is essential. Shadow APIs – that is, APIs which developers have allowed access and then forgotten about – make for easy hacking entry points. Removing these prior to PSD2 implementation makes for an easier path to better overall security.
For now, retailers, banks, and future TPPs have over a year to attain PSD2 compliance. Reaching that goal doesn’t just mean following the law. Any institution looking to provide the best quality service in a new digital environment must make security a paramount concern. Lucky for them, this just makes good business sense. Consumers naturally gravitate to whichever company has their best interest in mind. When it comes to keeping financial data safe, the best will always rise to the top.
