PSD3 ir PSR: ką prekybininkams iš tikrųjų reikės pakeisti

Pagal PSD2 kasdienes elgesio taisykles – grąžinimų terminus, atsakomybę už sukčiavimą, skundų nagrinėjimą – nustatė direktyva. Direktyvos netaikomos tiesiogiai. Kiekviena iš 27 valstybių narių turėjo perkelti PSD2 į savo nacionalinę teisę, ir kiekviena tai darė savo tempu, su savo spragomis ir savo lokaliu interpretavimu. Prekybininkas, veikiantis penkiose ES šalyse, iš esmės veikė pagal penkis šiek tiek skirtingus taisyklių rinkinius, nors visos jos formaliai įgyvendino „tą pačią“ direktyvą.

Naujasis paketas darbą paskirsto kitaip. PSD3 lieka direktyva ir daugiausia apima licencijavimą, priežiūrą bei rinkos prieigą mokėjimo įstaigoms – tai, kas veikia jūsų PSP reguliavimo statusą, o ne jūsų atsiskaitymo procesą. Elgesio taisyklės, kurios iš tikrųjų liečia prekybininkus – atsakomybė už sukčiavimą, grąžinimo įsipareigojimai, autentifikavimo reikalavimai, skundų nagrinėjimas – perkeliamos į PSR – reglamentą. Reglamentai taikomi tiesiogiai ir vienodai kiekvienoje valstybėje narėje, be nacionalinio perkėlimo etapo ir be vietinių formuluočių ypatumų.

Pagal teisinę suderintų tekstų analizę, tai sąmoningas atsakas į PSD2 sukeltą susiskaidymo problemą – PSR sukurtas tam, kad prekybininkams ir PSP suteiktų vieną vienodą taisyklių rinkinį, o ne 27 vietinius variantus („Freshfields“ suderintų tekstų apžvalga). Prekybininkams tai reiškia, kad atitikties patikra, atliekama jūsų Vokietijos padaliniui, kai PSR pradės galioti, turėtų duoti tuos pačius atsakymus, kaip ir patikra jūsų Airijos ar Portugalijos padaliniui. Tai realus supaprastinimas, tačiau tai taip pat reiškia, kad nebeliks argumento „vietinis reguliuotojas šiuo klausimu žiūri pro pirštus“.

PSD2 atsakomybės taisyklės buvo sukurtos aplink gana siaurą „neautorizuotos“ operacijos sampratą – tokios, kurios klientas nepatvirtino. Sukčiavimas nuo tada pažengė į priekį. Socialinės inžinerijos sukčiavimo schemos, kai sukčius apsimeta banko darbuotoju arba įtikina klientą tiesiogiai autorizuoti pavedimą, pagal senąją sistemą techniškai sukuria „autorizuotą“ operaciją, todėl klientas (o kartu ir tuo mokėjimu besiremiantis prekybininkas) istoriškai turėjo mažiau galimybių apginti savo teises.

PSR išplečia atsakomybę keliomis kryptimis, kurios svarbios prekybininkams:

• Sukčiavimas apsimetant – kai sukčius apsimeta PSP darbuotoju ar prekės ženklu – atsakomybę labiau perkelia mokėjimo paslaugų teikėjams, o ne palieka nuostolį padengti klientui.
• Nepavykimas pasiūlyti ar teisingai pritaikyti stiprų kliento autentifikavimą (SCA) atsakomybę uždeda tai šaliai grandinėje, kuri netinkamai jį pritaikė – tai apima ekvaizerius (acquirer) ir tam tikrose schemose – prekybininkus, kurie apeina autentifikavimą.
• Lėtas sukčiavimo pranešimų nagrinėjimas iš PSP pusės pats savaime gali sukurti atsakomybę – tai skatina bankus ir PSP greičiau reaguoti į sukčiavimo pranešimus, o ne kiekvieną skundą traktuoti kaip ilgą tyrimą.

Prekybininkui praktinė pasekmė ta, kad ginčai dėl sukčiavimo vis dažniau priklausys nuo įrodymų, kas vyko autentifikavimo metu, o ne vien nuo to, ar klientas tvirtina neautorizavęs mokėjimo. Tai reiškia, kad jūsų autentifikavimo žurnalai ir SCA rezultatų duomenys tampa jūsų ginčo įrodymų dalimi, o ne vien atitikties įrašu, kurį saugote ir pamirštate.

Vienas konkrečiausių pokyčių atsiskaitymo eigoms susijęs su patikrinimu, ar vardas, priskirtas sąskaitai, iš tikrųjų atitinka tą, kam mokėtojas mano siunčiantis pinigus. Tai remiasi Gavėjo patikros (Verification of Payee, VoP) mechanizmu, kuris jau privalomas momentiniams kredito pervedimams pagal ES Momentinių mokėjimų reglamentą, o naujasis mokėjimų paketas šią logiką išplečia toliau, apimant kitas mokėjimo paslaugas.

Praktiškai VoP reiškia, kad mokėtojo bankas patikrina sąskaitos savininko vardą pagal IBAN prieš baigiant pervedimą ir, radęs neatitikimą – „nesutampa“ arba „artimai sutampa“ – apie tai praneša mokėtojui prieš jam patvirtinant mokėjimą. Tai tiesiogiai nukreipta prieš autorizuotų pavedimų sukčiavimą, kai klientas apgaule priverčiamas pervesti pinigus į sąskaitą, priklausančią ne tam, kam jis mano.

Prekybininkams tai turi įtakos bet kuriai eigai, kai klientas inicijuoja banko pavedimą jums apmokėti – sąskaita-į-sąskaitą mokėjimo metodams, atvirosios bankininkystės inicijuotiems mokėjimams ar bet kuriam atsiskaitymo žingsniui, kuriame rodote savo, kaip gavėjo, duomenis, kad klientas galėtų atlikti pervedimą:

• Teisinis vardas, registruotas jūsų prekybininko banko sąskaitoje, turi tiksliai sutapti su prekybos pavadinimu, kurį klientai mato jūsų atsiskaitymo puslapyje, kitaip klientai pradės matyti neatitikimo įspėjimus, kurie atrodo kaip sukčiavimo požymiai, net kai viskas tvarkoje.
• Jei veikiate pagal prekybos pavadinimą, kuris skiriasi nuo jūsų juridinio asmens pavadinimo, dabar pats laikas juos suderinti arba užtikrinti, kad jūsų atsiskaitymo procesas aiškiai paaiškintų šį skirtumą, prieš klientui atsiduriant prieš VoP įspėjimą vidury mokėjimo.
• Bet kokia vidinė dokumentacija, kurioje nurodyti jūsų atsiskaitymo sąskaitos duomenys sutikrinimo tikslais, turėtų būti patikrinta pagal tai, kas iš tikrųjų registruota jūsų banke, nes pasenęs įrašas iškils kaip neatitikimas kiekvienam klientui, naudojančiam pervedimu grįstą metodą.

Tai atvejis, kai penkių minučių administracinis patikrinimas – įsitikinimas, kad jūsų banko sąskaitos registruotas vardas sutampa su jūsų parduotuvės prekės ženklu – padeda išvengti klientų sukeliamos sumaišties bangos, kai VoP tipo patikros bus plačiai taikomos.

PSD2 sąskaitas tvarkantiems bankams suteikė dvi galimybes atverti sąskaitos duomenis trečiosioms šalims: specialų API arba atsarginę sąsają, sukurtą ant jų esamų klientams skirtų interneto bankininkystės ekranų. Praktikoje atsarginės sąsajos dažnai būdavo lėtesnės, mažiau patikimos ir nenuosekliai prižiūrimos, todėl atvirosios bankininkystės pagrindu veikiančios atsiskaitymo eigos – mokėjimo per banką (pay-by-bank) parinktys, sąskaitos informacija rizikos vertinimui ir panašios funkcijos – buvo mažiau patikimos nei mokėjimai kortelėmis.

Naujoji sistema tai sugriežtina. Bankams bus taikomi aiškesni, labiau vykdomi įsipareigojimai dėl specialiosios sąsajos veikimo – artimesni jų pačių klientams skirtų kanalų patikimumui, su apibrėžtais lūkesčiais dėl veikimo laiko ir atsako greičio, o ne laisvai vykdomu „pagrįstų pastangų“ standartu, būdingu daliai PSD2 įgyvendinimo (MoFo PSD3/PSR pokyčių analizė).

Prekybininkams, kurie siūlo ar svarsto mokėjimo per banką ar kitas sąskaita-į-sąskaitą atsiskaitymo parinktis, tai svarbu dviem aspektais:

• Mažiau nepavykusių ar laiko limitą viršijusių autorizacijos bandymų turėtų reikšti mažiau paliktų krepšelių pervedimu grįstuose mokėjimo metoduose, kurie istoriškai atsilikdavo nuo kortelių pagal užbaigimo rodiklį – iš dalies dėl sąsajos patikimumo.
• Jei rizikos sprendimams remiatės sąskaitos informacijos paslaugomis – tikrinate sąskaitos nuosavybę ar balansą prieš išsiunčiant didelės vertės užsakymus – šie duomenų srautai turėtų tapti nuoseklesni, kad ant jų būtų galima kurti darbo procesus, o ne kurti pakartotinio bandymo ir atsarginę logiką.

Nė vienas iš šių pokyčių nepanaikina poreikio testuoti jūsų integraciją su realiu banko elgesiu, kai taisyklės įsigalios. Tačiau tai reiškia, kad bazinis patikimumas, su kuriuo testuojate, turėtų pagerėti.

Tai dalis, kuri dažniausiai praleidžiama daugumoje teisinių santraukų. Štai kas keičiasi jūsų pusėje.

Jūsų PSP ir ekvaizerio sutartys. Peržiūrėkite atsakomybės paskirstymo sąlygas savo esamose mokėjimo paslaugų sutartyse. PSD2 laikų sutartyse atsakomybės formuluotės dažnai rėmėsi senesniu, siauresniu „neautorizuotos operacijos“ apibrėžimu ir senosiomis SCA išimčių taisyklėmis. Kai PSR atsakomybės nuostatos pradės galioti, sutartys, kurios nebuvo atnaujintos, gali remtis standartais, kurie nebeatitinka įstatymo, o tai sukelia neaiškumą būtent tuo metu, kai reikia aiškumo – ginčo metu. Tiesiogiai paklauskite savo PSP, ar jų standartinės prekybininko sąlygos bus atnaujintos, kad atspindėtų PSR atsakomybės paskirstymą, ir gaukite atsakymą raštu, o ne darykite prielaidą, kad tai jau sutvarkyta.

• Jūsų atsiskaitymo eiga. Trys konkretūs dalykai, kuriuos reikia patikrinti:
• Įsitikinkite, kad su jūsų atsiskaitymo sąskaita susietas teisinis vardas sutampa su jūsų parduotuvės prekės ženklu, kad išvengtumėte nereikalingų VoP neatitikimo įspėjimų pervedimu grįstuose mokėjimo metoduose.
• Įsitikinkite, kad jūsų SCA patikrinimo eiga (3DS ar lygiavertė) korektiškai „degraduoja“ – klientas, atsisakantis pirkimo dėl techninio autentifikavimo žingsnio nepavykimo, o ne dėl to, kad jis pats jį atmetė, yra būtent tas scenarijus, kuriam skirtos naujosios atsakomybės taisyklės, ir jūs nenorite atsidurti neteisingoje pusėje, kai ginčas bus peržiūrimas.
• Jei siūlote mokėjimo per banką ar kitas sąskaita-į-sąskaitą parinktis, planuokite iš naujo išbandyti užbaigimo rodiklius, kai naujieji API veikimo įsipareigojimai įsigalios – patikimumo prielaidos, ant kurių kūrėte savo atsarginę logiką, gali nebebūti ribojantis veiksnys.

• Jūsų ginčų procesas. Įrodymai, lemiantys sukčiavimo ar atgalinio nurašymo (chargeback) ginčo baigtį, keičiasi. Ten, kur PSD2 laikų ginčai dažnai priklausė nuo to, ar SCA apskritai buvo pritaikytas, PSR laikų ginčai dažniau priklausys nuo to, kaip jis buvo pritaikytas, ar buvo atlikta VoP patikra ir koks buvo jos rezultatas, bei kaip greitai sukčiavimo pranešimas buvo perduotas toliau. Tai reiškia:
• Jūsų pagalbos komandai reikia prieigos prie autentifikavimo rezultatų žurnalų, o ne vien prie operacijos statuso, atsakant į ginčą.
• Jūsų dokumentacija dėl įrodymų pateikimo turėtų būti atnaujinta, kad kaip standartinis laukas įtrauktų VoP sutapimo/nesutapimo rezultatus, kai tik šie duomenys atsiras jūsų operacijų įrašuose.
• Vidiniai SLA terminai įtariamo sukčiavimo pranešimams perduoti jūsų PSP turėtų sugriežtėti, nes delsimas savaime tampa atsakomybės veiksniu, o ne neutraliu administraciniu žingsniu.

Perėjimas nuo PSD2 prie PSR yra mažiau susijęs su naujais, iš niekur atsiradusiais įsipareigojimais, o labiau su esamų spragų uždarymu.

Prekybininkai, kurie atsakomybę už sukčiavimą, SCA ir ginčų įrodymus traktavo pagal principą „kaip pasakys vietinis bankas“, pamatys, kad šis atsakymas nebegalios, kai tas pats reglamento tekstas bus taikomas kiekvienoje valstybėje narėje. Darbas yra administracinis – sutarčių, atsiskaitymo teksto ir įrodymų šablonų atnaujinimas – tačiau jis turi įvykti prieš bendrą taikymą, o ne po to, kai pirmasis ginčas pagal naujas taisykles atskleis spragą.

Niekas iš to nereikalauja perkelti jūsų atsiskaitymo į naują platformą. Tereikia jūsų PSP sutartį, registruotus sąskaitos duomenis ir ginčų įrodymų šablonus traktuoti kaip gyvus dokumentus, kuriuos reikia peržiūrėti pagal konkretų grafiką – būtent tam skirtas žemiau pateiktas kontrolinis sąrašas.

Tiksli bendro taikymo data priklauso nuo to, kada Oficialusis leidinys paskelbs galutinį tekstą, tačiau eiliškumas yra fiksuotas. Naudokite tai kaip darbinį tvarkaraštį, o ne fiksuotą terminą, ir patikslinkite datas, kai paskelbimas Oficialiajame leidinyje bus patvirtintas.

• Iki 2026 m. IV ketv. – tikimasi paskelbimo Oficialiajame leidinyje (2026 m. birželis–liepa). Kai jis įvyks, apskaičiuokite savo tikslią 21 mėnesio bendro taikymo datą ir įtraukite ją į savo atitikties kalendorių. Pradėkite PSP sutarties peržiūrą dabar, o ne laukite termino.
• 2027 m. eigoje – patvirtinkite savo PSP planą atnaujinti prekybininko sąlygas, kad jos atspindėtų PSR atsakomybės paskirstymą. Palyginkite jūsų atsiskaitymo sąskaitos registruotą teisinį vardą su jūsų atsiskaitymo puslapio prekės ženklu. Sudarykite žemėlapį, kurios jūsų atsiskaitymo eigos naudoja SCA, ir dokumentuokite dabartinę išimčių logiką, kad galėtumėte ją palyginti su galutiniais PSR reikalavimais.
• 2028 m. pradžioje – ištestuokite savo ginčų įrodymų procesą nuo pradžios iki galo: ar jūsų pagalbos komanda iš tikrųjų gali gauti SCA rezultatų ir VoP sutapimo duomenis apie operaciją pagal poreikį, ar tam reikia inžinerinio užklausimo (ticket)? Ištaisykite šią spragą prieš ją patikrinant gyvame ginče.
• Bendro taikymo momentu (numatoma 2028 m. kovas–balandis) – įsitikinkite, kad atnaujintos PSP sutartys pasirašytos, atsiskaitymo tekstas atspindi bet kokius gavėjo vardo reikalavimus, o jūsų ginčų dokumentacija apima naujuosius įrodymų laukus. Bendro taikymo datą traktuokite kaip momentą, iki kurio visa tai jau turėtų veikti, o ne kaip momentą, nuo kurio tik pradedate.

Cost+ veikia pagal IC++ (Interchange Plus Plus) kainodarą būtent todėl, kad manome, jog prekybininkai priima geresnius sprendimus, kai mokėjimo komponentai – interchange, scheme fee ir mūsų antkainis – yra matomi, o ne sujungti į vieną. Tas pats principas galioja ir reguliavimo pokyčiams: kuo anksčiau pamatysite, kas iš tikrųjų keičiasi atsakomybės ir įrodymų reikalavimuose, tuo mažiau trikdantis bus perėjimas. Jei norite aptarti, kaip jūsų dabartinė atsiskaitymo ir ginčų sistema dera su PSR tvarkaraščiu, susisiekite su mūsų komanda arba, peržiūrėdami sutartis, palyginkite savo dabartinę mokesčių struktūrą su paskelbta žemos rizikos kainodara mūsų svetainėje.