PSD3 ja PSR: mitä kauppiaiden pitää oikeasti muuttaa

PSD2:n alla päivittäiset toimintasäännöt – palautusten ajoitus, petosvastuu, valitusten käsittely – määritettiin direktiivillä. Direktiivit eivät sovellu suoraan. Kaikkien 27 jäsenvaltion oli saatettava PSD2 osaksi omaa kansallista lainsäädäntöään, ja kukin teki sen omalla aikataulullaan, omilla aukoillaan ja omalla paikallisella tulkinnallaan. Viidessä EU-maassa toimiva kauppias toimi käytännössä viiden eri sääntökirjan mukaan, vaikka kaikki väittivät panevansa täytäntöön "samaa" direktiiviä.

Uusi paketti jakaa työn eri tavalla. PSD3 pysyy direktiivinä ja kattaa pääasiassa toimilupa-asiat, valvonnan ja markkinoillepääsyn maksulaitoksille – asioita, jotka vaikuttavat PSP:si sääntelyasemaan, ei kassaasi. Toimintasäännöt, jotka oikeasti koskettavat kauppiaita – petosvastuu, palautusvelvoitteet, tunnistautumisvaatimukset, valitusten käsittely – siirtyvät PSR:ään, asetukseen. Asetuksia sovelletaan suoraan ja identtisesti kaikissa jäsenvaltioissa, ilman kansallista täytäntöönpanovaihetta ja ilman tilaa paikallisille kirjoitustavan oikuille.

Sovittujen tekstien oikeudellisen analyysin mukaan tämä on tarkoituksellinen vastaus PSD2:n aiheuttamaan hajanaisuusongelmaan – PSR on suunniteltu antamaan kauppiaille ja PSP:ille yksi yhtenäinen sääntökirja 27 paikallisen version sijaan (Freshfieldsin katsaus sovittuihin teksteihin). Kauppiaille tämä tarkoittaa, että vaatimustenmukaisuustarkastuksen, jonka teet saksalaiselle yksikölläsi, pitäisi PSR:n tullessa sovellettavaksi tuottaa samat vastaukset kuin irlantilaisen tai portugalilaisen yksikön tarkastus. Se on aito yksinkertaistus, mutta se tarkoittaa myös, ettei enää ole "paikallinen valvoja on tässä asiassa lepsu" -argumenttia turvana.

PSD2:n vastuusäännöt rakennettiin melko kapean "luvattoman" maksutapahtuman käsitteen ympärille – sellaisen, jota asiakas ei hyväksynyt. Petokset ovat kehittyneet siitä eteenpäin. Social engineering -huijaukset, joissa petkuttaja esiintyy pankin työntekijänä tai suostuttelee asiakkaan hyväksymään siirron suoraan itse, tuottavat vanhan kehyksen mukaan teknisesti "luvallisen" maksutapahtuman, mikä on historiallisesti jättänyt asiakkaalle (ja sitä kautta maksuun luottavalle kauppiaalle) vähemmän keinoja.

PSR laajentaa vastuuta muutamaan kauppiaiden kannalta olennaiseen suuntaan:

• Spoofing-tyyppinen petos – jossa petkuttaja esiintyy PSP:n henkilöstönä tai brändinä – siirtää enemmän vastuuta maksupalveluntarjoajille sen sijaan, että asiakas jää yksin kantamaan tappion.
• Vahvan asiakastodennuksen (SCA) tarjoamisen tai oikean soveltamisen laiminlyönti asettaa vastuun sille osapuolelle ketjussa, joka epäonnistui sen soveltamisessa oikein, mukaan lukien acquirer-osapuolet ja tietyissä virtauksissa kauppiaat, jotka kiertävät tunnistautumista.
• Hitaasti käsitellyt petosilmoitukset PSP:n taholta voivat itsessään synnyttää vastuun, minkä tarkoitus on kannustaa pankkeja ja PSP:itä nopeampaan petosilmoitusten käsittelyyn sen sijaan, että jokainen ilmoitus käsitellään pitkänä tutkintana.

Kauppiaalle käytännön vaikutus on, että petosriidat ratkeavat entistä enemmän tunnistautumisen aikana tapahtuneen todistusaineiston perusteella, ei vain sen perusteella, väittääkö asiakas jättäneensä maksun hyväksymättä. Se tekee tunnistautumislokeistasi ja SCA-tulostiedoistasi osan riitatapausten todistusaineistoa, ei vain vaatimustenmukaisuustietoa, jota säilytät ja unohdat.

Yksi konkreettisimmista kassaprosesseihin vaikuttavista muutoksista koskee sen varmistamista, että tilin nimi todella vastaa sitä, kenelle maksaja luulee lähettävänsä rahaa. Tämä rakentuu Verification of Payee (VoP) -mekanismin päälle, jota jo vaaditaan pikatilisiirroilta EU:n pikamaksuasetuksen nojalla, ja uusi maksupaketti laajentaa tätä logiikkaa edelleen maksupalveluihin.

Käytännössä VoP tarkoittaa, että maksajan pankki tarkistaa tilinomistajan nimen IBAN-tunnusta vasten ennen siirron toteutumista ja ilmoittaa mahdollisesta ristiriidasta – "ei täsmää" tai "täsmää osittain" – maksajalle ennen kuin hän vahvistaa maksun. Tämä on suunnattu suoraan valtuutettuun push-maksupetokseen, jossa asiakas huijataan siirtämään rahaa tilille, joka ei ole se, jonka hän luulee sen olevan.

Kauppiaille tämä vaikuttaa kaikkiin virtauksiin, joissa asiakas käynnistää tilisiirron maksaakseen sinulle – tililtä tilille -maksutapoihin, avoimen pankkitoiminnan kautta käynnistettyihin maksuihin tai mihin tahansa kassavaiheeseen, jossa näytät omat maksunsaajatietosi asiakkaan täytettäväksi siirtoa varten:

• Kauppatilillesi rekisteröidyn juridisen nimen on täsmättävä täsmälleen kassasivullasi näkyvän toiminimen kanssa, tai asiakkaat alkavat nähdä ristiriitavaroituksia, jotka näyttävät petossignaaleilta, vaikka mikään ei ole vialla.
• Jos toimit juridisesta nimestäsi poikkeavalla toiminimellä, nyt on aika joko yhdenmukaistaa ne tai varmistaa, että kassasi selittää eron selkeästi ennen kuin asiakas kohtaa VoP-varoituksen kesken maksun.
• Kaikki sisäinen dokumentaatio, jossa on tilitystilisi tiedot täsmäytystä varten, tulisi tarkistaa siitä, mitä pankkiisi on oikeasti rekisteröity, sillä vanhentunut tieto näkyy ristiriitana kaikille tilisiirtopohjaista maksutapaa käyttäville asiakkaille.

Tämä on tapaus, jossa viiden minuutin hallinnollinen tarkistus – sen varmistaminen, että pankkitilisi rekisteröity nimi täsmää verkkokauppasi brändäyksen kanssa – säästää sinut asiakkaita hämmentävältä aallolta, kun VoP-tyyppiset tarkistukset ovat laajasti voimassa.

PSD2 antoi tiliä ylläpitäville pankeille kaksi vaihtoehtoa tilitietojen avaamiseen kolmansille osapuolille: erillinen API tai varajärjestelmä, joka rakentuu pankin omien asiakkaille suunnattujen verkkopankkinäkymien päälle. Käytännössä varajärjestelmät olivat usein hitaampia, epäluotettavampia ja epäjohdonmukaisemmin ylläpidettyjä, mikä teki avoimeen pankkitoimintaan perustuvista kassavirtoista – pay-by-bank-vaihtoehdoista, riskiluokitukseen käytettävistä tilitiedoista ja vastaavista ominaisuuksista – epäluotettavampia kuin korttimaksuista.

Uusi kehys tiukentaa tätä. Pankeilla on jatkossa selkeämmät, paremmin täytäntöönpanokelpoiset velvoitteet erillisen rajapinnan suorituskyvylle – lähempänä omien asiakaskanaviensa luotettavuutta, määriteltyine odotuksineen käytettävyydelle ja vasteajoille, sen sijaan että noudatettaisiin höllästi valvottua "kohtuullinen yritys" -standardia, joka leimasi osaa PSD2:n täytäntöönpanosta (MoFo:n analyysi PSD3/PSR-kehityksestä).

Kauppiaille, jotka tarjoavat tai harkitsevat pay-by-bank- tai muita tililtä tilille -kassavaihtoehtoja, tällä on kaksi merkitystä:

• Vähemmän epäonnistuneita tai aikakatkaistuja vahvistusyrityksiä tarkoittaisi vähemmän hylättyjä ostoskoreja tilisiirtopohjaisissa maksutavoissa, jotka historiallisesti suoriutuivat kortteja huonommin loppuunsaattamisasteessa osin rajapintojen luotettavuuden takia.
• Jos nojaat tilitietopalveluihin riskipäätöksissä – varmistaaksesi tilinomistuksen tai tarkistaaksesi saldon ennen korkean arvon tilausten lähettämistä – näiden datavirtojen pitäisi muuttua johdonmukaisemmiksi rakentaa työnkulkuja varten, ei jonain, mitä varten sinun täytyy rakentaa uudelleenyritys- ja varakäsittelylogiikkaa.

Mikään tästä ei poista tarvetta testata integraatiotasi todellista pankkikäyttäytymistä vastaan sitten kun säännöt ovat voimassa. Se tarkoittaa, että perustason luotettavuus, jota vastaan testaat, todennäköisesti parantuu.

Tämä on osa, joka jää useimmista oikeudellisista yhteenvedoista pois. Tässä on se, mikä muuttuu sinun puolellasi pöytää.

PSP- ja acquirer-sopimuksesi. Käy läpi vastuunjakolausekkeet nykyisissä maksupalvelusopimuksissasi. PSD2-aikaisissa sopimuksissa vastuukieli oletti usein vanhan, kapeamman "luvattoman maksutapahtuman" määritelmän ja vanhat SCA-poikkeussäännöt. Kun PSR:n vastuusäännökset tulevat sovellettaviksi, päivittämättömät sopimukset saattavat viitata standardeihin, jotka eivät enää vastaa lakia, mikä luo epäselvyyttä juuri siinä hetkessä, kun tarvitset selkeyttä – kesken riidan. Kysy PSP:ltäsi suoraan, päivitetäänkö heidän vakiokauppiasehtonsa vastaamaan PSR:n vastuunjakoa, ja pyydä vastaus kirjallisena sen sijaan, että oletat asian olevan hoidossa.

• Kassaprosessisi. Kolme konkreettista tarkistettavaa asiaa:
• Varmista, että tilitystiliisi liitetty juridinen nimi täsmää verkkokauppasi brändäyksen kanssa, jotta vältät tarpeettomat VoP-ristiriitavaroitukset tilisiirtopohjaisissa maksutavoissa.
• Varmista, että SCA-tunnistautumisvirtasi (3DS tai vastaava) hoitaa virhetilanteet sujuvasti – asiakas, joka hylkää ostoksen siksi, että tunnistautumisvaihe epäonnistui teknisesti eikä siksi, että hän kieltäytyi siitä, on juuri se tilanne, jota uudet vastuusäännöt on suunniteltu tavoittamaan, etkä halua olla väärällä puolella, kun riitaa käsitellään.
• Jos tarjoat pay-by-bank- tai muita tililtä tilille -vaihtoehtoja, suunnittele loppuunsaattamisasteiden uudelleentestaus, kun uudet API-suorituskykyvelvoitteet tulevat voimaan – luotettavuusoletukset, joiden pohjalta rakensit varajärjestelmälogiikkasi, eivät välttämättä ole enää sitova rajoite.

• Riitaprosessisi. Petos- tai chargeback-riidan ratkaiseva todistusaineisto on muuttumassa. Siinä missä PSD2-aikaiset riidat ratkesivat usein siitä, sovellettiinko SCA:ta ylipäätään, PSR-aikaiset riidat ratkeavat useammin siitä, miten sitä sovellettiin, ajettiinko VoP-tarkistus ja mikä sen tulos oli, ja miten nopeasti petosilmoitus eskaloitiin. Tämä tarkoittaa:
• Tukitiimisi tarvitsee pääsyn tunnistautumistulosten lokeihin, ei vain maksutapahtuman tilaan, kun se vastaa riitaan.
• Todistusaineiston toimitusohjeistuksesi tulisi päivittää sisältämään VoP-täsmäys/ei-täsmäys-tulokset vakiokenttänä, kun tämä tieto on olemassa maksutapahtumatiedoissasi.
• Sisäisten SLA-tavoitteiden epäillyn petoksen ilmoittamisesta PSP:lle tulisi tiukentua, sillä viivästys itsessään muuttuu vastuutekijäksi eikä neutraaliksi hallinnolliseksi askeleeksi.

Siirtymä PSD2:sta PSR:ään koskee vähemmän tyhjästä syntyviä uusia velvoitteita ja enemmän olemassa olevien aukkojen sulkeutumista.

Kauppiaat, jotka kohtelivat petosvastuuta, SCA:ta ja riitatodistusaineistoa "sen mukaan, mitä paikallinen pankki sattuu sanomaan", huomaavat, ettei tämä vastaus enää päde, kun samaa asetustekstiä sovelletaan kaikissa jäsenvaltioissa. Työ on hallinnollista – sopimusten, kassatekstien ja todistusmallien päivittämistä – mutta se on tehtävä ennen yleistä soveltamista, ei sen jälkeen, kun ensimmäinen uusien sääntöjen mukainen riita paljastaa aukon.

Mikään tästä ei vaadi kassajärjestelmäsi uudelleenrakentamista. Se vaatii, että kohtelet PSP-sopimustasi, rekisteröityjä tilitietojasi ja riitatodistusmallejasi elävinä asiakirjoina, jotka tarvitsevat tarkastuskierroksen määrätyn aikataulun mukaan – ja siihen alla oleva tarkistuslista pyrkii.

Tarkka yleisen soveltamisen päivämäärä riippuu siitä, milloin virallinen lehti julkaisee lopullisen tekstin, mutta järjestys on kiinteä. Käytä tätä työskentelyaikataulun apuna kiinteän määräajan sijaan ja vahvista päivämäärät, kun virallisen lehden julkaisu on vahvistettu.

• Vuoden 2026 4. neljännekseen mennessä – Julkaisu virallisessa lehdessä odotetaan (kesä–heinäkuu 2026). Kun teksti on julkaistu, laske oma 21 kuukauden yleisen soveltamisen päivämääräsi ja merkitse se vaatimustenmukaisuuskalenteriisi. Aloita PSP-sopimuksen tarkastus nyt sen sijaan, että odotat määräaikaa.
• Vuoden 2027 aikana – Vahvista PSP:si suunnitelma kauppiasehtojen päivittämisestä vastaamaan PSR:n vastuunjakoa. Tarkasta tilitystilisi rekisteröity juridinen nimi kassabrändäystäsi vasten. Kartoita, mitkä kassavirroistasi käyttävät SCA:ta, ja dokumentoi nykyinen poikkeuslogiikka, jotta voit verrata sitä lopullisiin PSR-vaatimuksiin.
• Vuoden 2028 alkupuoli – Testaa riitatodistusprosessisi päästä päähän: pystyykö tukitiimisi oikeasti hakemaan SCA-tuloksen ja VoP-täsmäystiedon maksutapahtumalle pyynnöstä, vai vaatiiko se kehitystiketin? Korjaa tämä aukko ennen kuin sitä testataan aidossa riitatilanteessa.
• Yleisessä soveltamisessa (arviolta maalis–huhtikuu 2028) – Vahvista, että päivitetyt PSP-sopimukset on allekirjoitettu, kassateksti heijastaa mahdollisia maksunsaajan nimeä koskevia vaatimuksia ja riitadokumentaatiosi sisältää uudet todistuskentät. Kohtele yleisen soveltamisen päivämäärää pisteenä, jolloin kaiken edellä mainitun pitäisi olla jo käynnissä, ei pisteenä, jolloin aloitat.

Cost+ toimii IC++ (Interchange Plus Plus) -hinnoittelulla juuri siksi, että uskomme kauppiaiden tekevän parempia päätöksiä, kun maksun osatekijät – interchange, scheme fee ja meidän markup – ovat näkyvissä eikä yhdistettynä. Sama periaate koskee sääntelymuutoksia: mitä aikaisemmin näet, mikä vastuu- ja todistusvaatimuksissa oikeasti muuttuu, sitä vähemmän häiritsevä siirtymä on. Jos haluat käydä läpi, miten nykyinen kassa- ja riitatilanteesi asettuu PSR-aikataulua vasten, ota yhteyttä tiimiimme tai vertaa nykyistä hinnoittelurakennettasi julkaistuun low-risk-hinnoitteluun sivustollamme samalla, kun käyt sopimuksia läpi.