När det gäller onlinebetalningar och kreditkortshantering har EU-återförsäljare beviljats en spärr. EU:s reviderade betaltjänstdirektiv, känt som PSD2, har förlängt sin efterlevnadsperiod till mars 2021, vilket gör att återförsäljare och banker kan vara säkra medan lagstiftningen förblir i limbo. Och ändå betyder en förlängning av tidsfristen inte att företag kan vila på sina lagrar. Konsumenter, regeringar och utvecklare förväntar sig att banker och andra tjänster är redo att följa efter, helst före deadline i mars 2021.
Om författaren Subho Halder är medgrundare och CTO för Appknox. Viktigast av allt är att hackare är medvetna om denna sårbarhetsklyfta. PSD2-reglerna syftar till att öka konkurrensen och ge konsumenterna fler valmöjligheter, men ger också ytterligare säkerhet för viktiga bankuppgifter. Att lämna denna information osäker är ett riskabelt försök för brottslingar. Låt oss se var vi är idag med dessa standarder och hur företag som är involverade i e-handel kan implementera SecDevOps bästa praxis i sin PSD2-efterlevnad.
1: API-status
I mars 2019 är 41 % av EU-bankerna fortfarande inte kompatibla med framtida PSD2-standarder. Även om det är mindre än hälften och de exakta procentsatserna varierar från land till land, är huvudorsaken till att bankerna drar på sig densamma: API-testning. Behovet för banker att skapa API:er för transaktionsbetalningsdata finns i första hand i checklistan för PSD2-efterlevnad. Dessa API:er måste bland annat tillhandahålla realtidsåtkomst, bedrägeriövervakning, multi-faktor användarautentisering och användarbeteendeanalys. Med alla dessa funktioner är det inte svårt att se varför vissa institutioner har varit långsamma med att följa. Dessa API:er kommer dock att bli grunden för digitala finansiella transaktioner under 2020-talet och framåt. Företag och finansiella tjänsteleverantörer kommer att använda bank-API:er för att tillhandahålla sina egna betalningssystem, eventuellt skapa sina egna API:er för att fullt ut använda betalnings- och beteendedata. Faktum är att banker själva också skulle kunna bli tredjepartsleverantörer (TPP), både genom att skapa och använda andra parters API:er. Den förväntade effekten av denna ökade konkurrens är att ge konsumenterna fler valmöjligheter och därmed lägre priser, ett ädelt mål för alla medborgarinriktade statliga organ. På ytan kan PDS2-standarder faktiskt förbättra förtroendet och säkerheten i digitala finansiella transaktioner. Det väcker frågan om hur banker skapar sina API:er och vem som slutar använda dem. Och hur.
2. Säkerhet mot bedrägerier: vad konsumenter och institutioner behöver veta
Kärnan i PDS2 är API:er som banker kommer att skapa för att tillhandahålla tjänster till TPP:er. Säkerhet är av största vikt när banker bygger API:er: de har enorm tillgång till våra viktigaste finansiella data. Alla detaljer som hamnar i händerna på opålitliga karaktärer är föremål för katastrof. Som vi noterade har mycket av diskussionen hittills fokuserat på dessa bank-API:er. Mindre uppmärksamhet har ägnats åt vad PPT:er och andra institutioner kan göra med sina egna API:er. Med andra ord, vilka säkerhetsregler finns det för PPT:er? Sanningen är att väldigt lite. TPP har en stor fördel och en stor brist jämfört med PDS2, som är en i samma. För det första är TPP inte föremål för samma stränga regler som banker. Detta är en av de viktigaste drivkrafterna för PDS2: att tillåta dessa TPP att erbjuda betalningsalternativ innebär mer flexibilitet för konsumenterna. De är inte heller bundna till samma äldre IT-infrastruktur som många banker. Denna ökade rörlighet kostar dock. Om en TPP inte kräver lika mycket stelhet för att börja bearbeta transaktioner, betyder det att dess säkerhet också är mindre strikt? Hur vet konsumenterna om deras nya betalningsleverantör hanterar säkerheten för deras data?
3: Definiera bästa praxis i PDS2
För det första måste OPP vara medvetna om de risker de står inför. Bedrägeriattacker, där illvilliga användare skapar falska kontoringar för att utnyttja olika fördelar, ökade med 26 % förra året, även när fler och fler banker implementerar 2FA och andra lösningar för att bekämpa dessa brott. Till viss del kan PPT:er förbättra säkerheten för kunddata. De kan dela information med varandra eller med de banker vars API:er de använder. TPP:er med starkare säkerhetsprotokoll har ett bättre försäljningsargument till nya kunder: den exakta typen av konkurrens som PDS2 tros provocera fram. Samtidigt måste nya utmaningar mötas innan ett brott inträffar. Å ena sidan är övervakningen av de använda API:erna väsentlig. Varje banks API kommer ständigt att verifieras eftersom många TPP:er kommer att förlita sig på det för att tillhandahålla tjänster till sina kunder. API:er skapade av dessa tredjepartsleverantörer kommer att testas mindre noggrant. Som sådan blir SecDevOps portvakten mellan ekonomisk säkerhet och hackermissbruk. Det finns ett antal steg varje part kan ta nu för att hålla PSD2 säker senare. Först och främst är det viktigt att inventera de API:er som redan används. Ghost API, det vill säga API:er som utvecklare har gett tillgång till och sedan glömt bort, gör det lättare att hacka ingångspunkter. Att ta bort dem innan PSD2 implementeras banar väg för bättre övergripande säkerhet. För närvarande har återförsäljare, banker och framtida PPT:er mer än ett år på sig att följa PSD2. Att uppnå detta mål innebär inte bara att följa lagen. Varje institution som vill tillhandahålla den bästa kvaliteten på tjänsterna i en ny digital miljö måste göra säkerheten till en primär fråga. Lyckligtvis för dem är det affärsmässigt meningsfullt. Konsumenter dras naturligtvis till det företag som är viktigast för dem. När det gäller finansiell datasäkerhet kommer det bästa alltid att komma överst.