Wat hebben 2FA, OTP, TRA, MOTO, CIT en MIT met elkaar gemeen? Het zijn allen afkortingen die gebruikt worden in het Strong Customer Authentication proces. Om te voldoen aan SCA zijn er diverse technische vraagstukken en oplossingen. Hieronder lichten we deze toe.
SCA vereist dat er bij online creditcardbetalingen een (extra) authenticatiestap moet plaatsvinden. Waar tot voor kort het creditcardnummer, vervaldatum en de CVC-code voldoende waren, moeten klanten nu minstens twee van de drie extra authenticatiemethoden gebruiken als ze online voor iets willen betalen, te weten; iets wat je hebt (smartphone), weet (wachtwoord/pincode) of wat je bent (vingerafdruk/gezichtsherkenning).
One Time Password (OTP)
Een ander voordeel van deze nieuwe wetgeving wat zeker het aantal fraudegevallen zal laten dalen, is de verplichte introductie van een OTP. In veel landen zijn de authenticatie opties langzaam uitgebreid, van bijvoorbeeld een creditcardnummer, aangevuld met vervaldatum en later ook de CVC of zelfs een Adres Verificatie Service (AVS)’ en later ook een password. Maar uiteindelijk zijn dit allemaal statische gegevens, welke door phishing alsnog kunnen worden ontvreemd.
PAY. ziet het regelmatig voorkomen dat volledige lijsten met kaartnummers, inclusief CVC en geldige 3D Secure verificatie worden misbruikt. In de meeste gevallen komen deze frauduleuze pogingen onze VERIFY-module niet door. Aldus Herbert Koebrugge (Risk Officer bij PAY.)
Door het verbod op een statische password zal de levensduur van via phishing verkregen gegevens aanzienlijk worden verkort. Met een lager fraude ratio tot gevolg. Minder fraude betekent minder kosten voor financiële instellingen, beter voor het consumentenvertrouwen en is uiteindelijk goed voor de ondernemer.
3D Secure 2.X - een uitgebreidere versie van 3D Secure
3D Secure 1.0 voldoet niet aan alle regels opgenomen in de PSD2. Sommige banken gebruiken nog statische wachtwoorden en zijn technisch niet voorbereid op een OTP. Binnen dit protocol is er geen mogelijkheid opgenomen voor ‘exemptions’. Banken missen hierdoor waardevolle informatie om het risicoprofiel te kunnen bepalen, met het gevolg dat er amper betalingen frictieloos kunnen worden afgehandeld. Dit moet 3D Secure 2.X gaan oplossen. Deze is gestart als 2.0 en ondertussen via de korte tussenversie 3D Secure 2.1 geëvalueerd naar 3D Secure 2.2. Hierbij ontvangt de Issuer meer informatie over de transactie en de Merchant bij het verificatieverzoek. Deze informatie kan worden gebruikt voor een betere riskanalyse. Een Issuer kan op deze wijze bepalen dat een OTP voor een bepaalde transactie niet nodig is. Dit gebeurt in beperkte gevallen ook bij 3D Secure 1.0. Bijvoorbeeld bij American Express in combinatie met SafeKey bij online betalingen van lage waarde, of vanaf devices (bijvoorbeeld tablets of mobiele telefoons) welke al eerder betalingen hebben uitgevoerd.
Transaction Risk Analysis (TRA)
Indien een PSP een goede risicoanalyse kan maken, mag zij voor de Merchant een uitzondering op de SCA aanvragen of juist forceren dat er wel volledig wordt geverifieerd.
Uitzondering op SCA by low value payment en lage fraude Merchants:
| < 30 euro met totaal van < 100 euro of 5x |
Exemption mag altijd |
| <100 euro |
Fraude < 0,13% |
| <250 euro |
Fraude < 0,06% |
| <500 euro |
Fraude < 0,01% |
Indien er een exemption is aangevraagd door de Merchant (via PAY) dan is zij verantwoordelijk voor eventuele fraude. Indien de Bank de exemption aanvraagt, dan is zij verantwoordelijk voor de fraude (liability shift).
Een issuer mag altijd alsnog 3D Secure vragen, ook als de Merchant een exemption aanvraagt. Bijvoorbeeld als de kaart al vijf keer gebruikt is met een exemption voor de bestelling bij andere Merchants.
Onze VERIFY-module zorgt voor lage frauderatio, waardoor de issuer meer betalingen frictieloos zal verwerken” Aldus Olaf Kok.
Merchant whitelisting
De kaarthouder heeft de mogelijkheid om een bepaalde ondernemer te whitelisten. Deze optie is zonder goede automatisering nogal complex en arbeidsintensief voor de issuer. Het whitelisten gaat op basis van de ‘bedrijfs- of handelsnaam’. PAY. geeft deze mee bij elke betaling, maar na een belrondje langs enkele creditcardmaatschappijen is het ons niet volledig duidelijk hoe een consument de onderneming als betrouwbaar kan markeren (whitelisten). Het 3Dsecure 2.X systeem is wel voorbereid op een verzoek van de merchant aan de consument, om direct te whitelisten, maar praktijkvoorbeelden zijn nog niet gezien.
NON EU betalingen (One leg transactions)
Indien de acquirer of issuer zich buiten de EU bevinden, hoeft er niet te worden voldaan aan de SCA-regels. PAY. werkt enkel met acquierers binnen de EU. Dus voor jou als Merchant van PAY. is deze regel eenvoudiger uit te leggen: Bevindt de bank van de kaarthouder zich buiten de EU, dan is SCA niet verplicht.
“Ik ben blij dat al deze veranderingen door PAY. in de gaten worden gehouden. Voor mij verandert er dus weinig, ik kijk toe, en hoop dat mijn klanten soepel kunnen blijven betalen". Aldus één van onze merchants.
Pinbetalingen
Bij pinbetalingen via een PAY. terminal voldoe je reeds aan de regels. Alle consument betaalkaarten in de EU die betrokken zijn bij deze regelgeving zijn voorzien van een pincode (= iets wat alleen een kaarthouder weet). Indien er een exemption (low value payment) kan worden gemaakt, accepteert de betaalautomaat de transactie zonder pincode. Indien de consument meer dan het toegestane aantal betalingen heeft uitgevoerd zal de automaat vragen om de pincode.
Ook zakelijke betaalkaarten en de kaarten buiten de EU zijn meestal voorzien van een pincode (>99%). Indien er toch een handtekening nodig is, ontvang je vanuit het betaalscherm of onze API een ‘handtekening nodig’ melding. Gebruik je PAY. via een kassaleverancier dan is deze functionaliteit reeds geïmplementeerd.
MOTO en MIT (Merchant Initiated transaction)
Maak je gebruik van het MOTO (Mail Order Telephone Order) platform van PAY of van MIT-transacties, dan is er geen SCA-verplichting. In combinatie met tokenisatie heb je meestal voldoende aan de laatste 4 getallen van de creditcard of de naam van de kaarthouder om de MOTO transactie te starten. Een token koppel je eenvoudig aan het account van een gebruiker in je eigen systeem, om zo een betaling te verwerken.
