Ustaljena praksa i Zakon o platnom prometu zahtijevaju od banaka da klijentima šalju periodične (mjesečne) izvještaje o izvršenim transakcijama i stanju računa, poznato i kao bankovni ili financijski izvod. Izvještaji/izvodi uobičajeno se šalju fizičkom poštom ili elektroničkom poštom. E-pošta, koja je sad uobičajen, ne zadovoljava standarde zaštite osobnih podataka. Financijski podaci osobni su podaci klijenta banke. Poslani ovim medijem izloženi su brojnim povredama podataka. Obrazlažemo siguran način pristupanja mjesečnim izvješćima, preko klijentskih portala, uz zadovoljavanje Zakona o platnom prometu.
Opća uredba o zaštiti podataka, Uredba (EU) 2016/679 (eng. General Data Protection Regulation, dalje u tekstu: GDPR ili Opća uredba) ušla je u primjenu u zemljama Europske Unije, uključujući Hrvatsku u svibnju 2018. Postavlja načela zaštite osobnih podataka, od kojih je jedno sigurnost, te tehničke i organizacijske mjere zaštite. Navodi da „povreda osobnih podataka” znači kršenje sigurnosti koje dovodi do slučajnog ili nezakonitog uništenja, gubitka, izmjene, neovlaštenog otkrivanja ili pristupa osobnim podacima koji su preneseni, pohranjeni ili na drugi način obrađivani.
Opća uredba definira u članku 9. posebne kategorije osobnih podataka čija je obrada u načelu zabranjena, a dopuštena je u iznimnim uvjetima. To su podaci koji otkrivaju rasno ili etničko podrijetlo, politička mišljenja, vjerska ili filozofska uvjerenja ili članstvo u sindikatu te genetski podaci, biometrijski podaci u svrhu jedinstvene identifikacije pojedinca, podaci koji se odnose na zdravlje ili podaci o spolnom životu ili seksualnoj orijentaciji pojedinca.
Financijski podaci nisu u ovoj kategoriji, međutim smatraju se visoko osjetljivim podacima. Prema britanskom nadzornom tijelu Information Commissioner's Office (ICO)1 podaci su to koji se odnose na kreditne kartice, bankovne račune ili druge financijske podatke pojedinca ili skupine pojedinaca. To može uključivati informacije poput plaće ili stopa beneficija koje primaju. Iako su ljudi obično vrlo osjetljivi na ove informacije i kriminalci ih mogu iskoristiti za krađu ili prijevaru, ne klasificira se kao posebna kategorija podataka.
Takvi podaci, a prema tome i podaci koje obrađuje financijska institucija često su meta napada. Saznanje o tome koliko netko ima novca na računu, a pogotovo podaci za dokazivanje identiteta (autentifikacija) kao što su podaci o bankovnim karticama (broj kartice) te još više autentifikacija pristupa računu (pin, CVV broj) iznimno su zloupotrebljivi.
E-pošta jedna je od najpopularnijih i najjednostavnijih načina komunikacije. E-pošte koje koristimo u svakodnevnoj komunikaciji (od javno dostupnih, uglavnom besplatnih usluga kao što su Microsoft ili Google) bez dodatne zaštite nisu kriptirani što znači da ih napadači trećih strana mogu presresti. Korisnici su izloženi i phishingu, odnosno mailovima koji se predstavljaju kao da dolaze od autorizirane strane, a zapravo se lažno predstavljaju. Ove e-poruke često sadrže poveznice na zlonamjerne web stranice ili privitke koji mogu zaraziti računalo korisnika zlonamjernim softverom. Ljudska greška još je jedan faktor nesigurnosti. Ponekad će se dogoditi da e-poruku pošaljemo na krivu adresu. Možda smo je pogrešno pohranili u kontakte, pogrešno unijeli primatelja ili odabrali pogrešnu adresu iz padajućeg izbornika kontakata i prebrzo kliknuli „Pošalji“. Zbog svega toga ljudima se preporučuje da nikada ne šalju osjetljive ni povjerljive informacije mailom, uključujući i financijske podatke.
Kako postići sigurnost u dnevnoj, privatnoj uporabi e-pošte? Preporučuje se osjetljive podatke staviti u privitak (attachment) koji se zaštiti šifrom, a šifra se primatelju pošalje drugim kanalom (npr. SMS-om). Tijelo poruke treća strana moći će presresti i pročitati, ali privitak neće moći otvoriti. Sad već govorimo o više-faktorskoj autentifikaciji (eng. Multifactor Authentication, dalje u tekstu MFA). Primatelj mora na više načina, u ovom slučaju dva (lozinka za pristup mailu i unos šifre koju je primio SMS-om, odnosno njegov telefonski broj), dokazati da je to on.
Poslovne pružatelji usluga e-pošte, koje tvrtka (financijska institucija) plati, imaju dodatnu razinu zaštite, primjerice enkripciju. Međutim ako enkripcija nije forsirana end-to-end, i dalje postoji rizik presretanja na nekom od servera kojima poruka prolazi. Većina pružatelja usluga e-pošte koristi TLS (Transport layer security), koji kriptira poruke samo tijekom prijenosa. Nakon što poruka stigne u pristiglu poštu primatelja, obično se pohranjuje nekriptirana. Enkripcija ne može biti end-to-end ako obje strane (pošiljatelj i primatelj – klijent) ne koriste napredne protokole kao što su S/MIME ili PGP. Navedeno je rijetko implementirano. Kad e-poruka stigne na server primatelja izložena je napadima. Ostaje u primljenoj pošti, radi se backup pošte i ranjiva je za buduće napade.
U prethodnom poglavlju utvrdili smo da slanje osjetljivih financijskih podataka e-poštom nikako nije preporučljivo. No možemo li primijeniti slanje financijskih podataka u privitku na koji je primorana MFA? U teoriji - da, kad je riječ o pojedinačnom slanju maila, primjerice od strane bankovnog službenika klijentu. Ali to bi zahtijevalo pojedinačne korake od strane bankovnog službenika koje bi on mogao zaboraviti ili zaobići, iako se koraci propišu politikom.
U pomoć mogu priskočiti, a i osigurati usklađenost s regulativama kao što su GDPR ili NIS2, Data Loss Prevention (Sprečavanje gubitka podataka, dalje u tekstu DLP) alati. Sprečavanje gubitka podataka štiti osjetljive ili kritične informacije od gubitka ili curenja identificiranjem informacija na temelju kriterija.
Data loss (gubitak podataka) često se opisuje kao povrede podataka, curenje podataka ili izbacivanje (eksfiltracija) podataka.
Holdsworth i Kosinski za IBM blog definiraju ih ovako2:
Kao što definicija kaže, DLP alati identificiraju podatke na temelju kriterija. Tako je prvi korak DLP-a identificiranje što sve spada pod osjetljive podatke (u kontekstu biznis logike, a ne GDPR-a). Za to identificiranje potrebno je provesti procjenu rizika.
Nakon toga organizacija postavlja pravila koja definiraju kako se mogu obrađivati različite vrste podataka, a DLP alati provode ta pravila kako bi kontrolirali što korisnici (zaposlenici) mogu učiniti s podacima. DLP alati tradicionalno se oslanjaju na statička pravila i podudaranje ključnih riječi kako bi zaštitili podatke. Međutim, moderna DLP rješenja temeljena na umjetnoj inteligenciji (eng. Artificial intelligence, dalje u tekstu AI) uključuju prediktivnu analitiku i uvide u ponašanje.
U slučaju kršenja pravila ili sumnjivih aktivnosti (tražeći obrasce, klasifikatore, etikete), DLP sustavi upozoravaju administratore i mogu poduzeti unaprijed definirane radnje, poput blokiranja prijenosa podataka. Tu ljudska greška ili namjera ne može zaobići slanje osjetljivog podatka, kao što je broj bankovne kartice, e-poštom.
Neka DLP rješenja za e-poštu automatski primjenjuju enkripciju tijekom prijenosa, dok druga omogućuju odabir e-poruka za kriptiranje.
Prema blogu Najbolje prakse za sprječavanje gubitka podataka e-pošte (DLP) (2026.) Inbox Zero, AI rješenja koje pomaže DLP-ima za upravljanje e-porukama, navodi se da organizacije nakon klasifikacije podataka mogu postaviti pravila poput: Podaci o platnim karticama ne smiju se slati e-poštom izvan organizacije, nikada. Osobni podaci korisnika mogu se slati e-poštom izvan organizacije samo ako su šifrirani i poslani na odobrene partnerske domene. Izvorni kod i API ključevi ne smiju napustiti tvrtku putem e-pošte. Dokumenti o ljudskim resursima i naknadama ne smiju se slati e-poštom izvan organizacije.3
Prema istom blogu, većina rizika od curenja e-pošte odnosi se na odlazne poruke (na adrese izvan banke). Stoga se preporučuje izgraditi zasebnu logiku za različite kontekste primatelja. Interna komunikacija trebala bi imati nižu napetost (frikciju) i omogućiti poništavanje s opravdanjem. Interna komunikacija prema domenama pouzdanih partnera zahtijeva umjerene kontrole s enkripcijom gdje je potrebno. Interne domene prema nepoznatim vanjskim domenama trebale bi imati veću napetost i karantenu za osjetljivi sadržaj. A interne domene prema osobnim domenama e-pošte (gmail.com, yahoo.com itd.) trebale bi imati najstrože kontrole.4
Za određene e-poruke može se postaviti upozorenje. Primjerice ako su usmjerene na osobne domene e-pošte, može se postaviti dodatno pitanje: jeste li sigurni da želite poslati?
DLP ne može prisiliti vanjskog pružatelja usluga (poput osobnog Gmaila ili Yahooa) da usvoji MFA protokole organizacije (banke). Međutim, DLP može djelovati kao čuvar pristupa poduzimajući određene radnje ako zaposlenik pokuša poslati osjetljive podatke na te osobne adrese.
Budući da DLP ne može prisiliti vanjske pružatelje usluga na MFA, ostaju za rješavanje brojni problemi. Djelatnik banke može pogrešno unijeti adresu e-pošte klijenta pri prvom kontaktu i e-poruka s izvodom može otići krivoj osobi ako pogrešno unesena adresa e-pošte slučajno postoji (što je dosta vjerojatno). Automatizam kojim se izvodi šalju konstantno će izvod slati pogrešnoj osobi ako ta osoba ne reagira.
Također, problem je ako klijenti ne pristaju na end-to-end enkripciju ili ako ju je zahtjevno implementirati.
Sigurnim rješenjem i zlatnim standardom za primanje izvoda danas se smatra klijentski portal (web platforma) na kojem klijent može pregledavati izvod.
Klijentski portal u skladu s GDPR-om zahtijeva end-to-end enkripciju, detaljne kontrole pristupa, sveobuhvatne logove i kontrole smještaja podataka kako bi se ispunili regulatorni zahtjevi.
Proces uobičajeno započinje tako što klijent dobije poveznicu na portal na e-poštu. Međutim na portal se (slično usluzi internet bankarstva) ne može prijaviti bez MFA. MFA može se osigurati šiframa poslanima SMS-om, autentifikacijskim aplikacijama, biometrijskom verifikacijom, tokenima. Prisiljena MFA izbjegava sve moguće pogreške u adresi e-pošte ili broju telefona.
Banke i klijenti mogu se suočiti s problemom dodatne edukacije klijenata, jer pristup klijentskim portalima zahtijeva edukaciju za korištenje još jedne platforme. Međutim to ne bi trebala biti prepreka za uvođenje. Pristup treba biti krajnje pojednostavljen, s osiguranim uputama za upotrebu i dostupnu pomoć agenata korisničke podrške.
Prema Zakonu o platnom prometu ("Narodne novine" br. 66/18, 114/22, 136/24.), članak 3. stavak 1. točka 41. pouzdana autentifikacija klijenta jest autentifikacija na osnovi uporabe dvaju ili više elemenata koji pripadaju u kategoriju znanja (nešto što samo korisnik zna), posjedovanja (nešto što samo korisnik posjeduje) i svojstvenosti (nešto što korisnik jest) koji su međusobno neovisni, što znači da povreda jednog ne umanjuje pouzdanost drugih i koja je osmišljena na takav način da štiti povjerljivost autentifikacijskih podataka, pri čemu najmanje dva od navedenih elemenata moraju pripadati različitoj kategoriji.
Enkripcija se u ovom slučaju u prijenosu može osigurati TLS-om, a u mirovanju (na serverima) različitim algoritmima. Budući da je riječ o osjetljivim podacima, poželjno je osigurati end-to-end enkripciju.
Članak 30. GDPR-a nalaže vođenje evidencije o aktivnostima obrade. Prema Moxo platformi, jednoj od platformi koja izgrađuje klijentske portale i omogućuje praćenje tijeka podataka, to za klijentske portale znači vođenje zapisa (logova)5:
I u slučaju drugih podataka, broja kartice i sl., praćenjem zapisa tijeka podataka, osigurava se da djelatnik banke ne može poslati financijske podatke na svoju ili druge privatne ili neautorizirane adrese e-pošte.
Postoje legitimne svrhe u koje klijent može zatrebati poslati nekome svoj bankovni izvod. Primjeri su dokazivanje financijske stabilnosti pri zahtjevu za kredit, prijavi za vizu ili imigracijsku dozvolu ili prijavi za određene poslove. To su legitimne svrhe i klijent može skinuti izvod u pdf obliku na svoje računalo. Kad bi ga primio e-poštom, klijent bi ga mogao nekontrolirano prosljeđivati na druge adrese e-pošte. To bi mogao uraditi iz neupućenosti izlaganja osobnih financijskih podataka ili slučajnim klikom na „Proslijedi“, što se izgledno može dogoditi.
Budući da se prema Zakonu o platnom prometu klijentu (platitelju) mora omogućiti pohrana i reprodukcija informacija u nepromijenjenom obliku, na klijentskom portalu bankovni izvod treba biti dostupan u pdf obliku.
Prema Zakonu o platnom prometu, članak 29.:
Informacije za platitelja o pojedinim platnim transakcijama
„(1) Pružatelj platnih usluga platitelja dužan je bez odgađanja nakon terećenja računa za plaćanje platitelja za iznos pojedine platne transakcije ili, ako se platitelj za tu platnu transakciju ne koristi računom, nakon primitka naloga za plaćanje platitelju dati na način predviđen člankom 24. stavkom 1. ovoga Zakona sve sljedeće informacije:
1. referenciju koja omogućuje platitelju identifikaciju svake platne transakcije i, ako je primjenjivo, informacije koje se odnose na primatelja plaćanja
2. iznos platne transakcije u valuti u kojoj je terećen račun za plaćanje platitelja ili u valuti koja je korištena na nalogu za plaćanje
3. ukupan iznos svih naknada za tu platnu transakciju, iznos svake pojedine naknade i kamate koje plaća platitelj
4. ako platna transakcija uključuje preračunavanje valute, tečaj te iznos platne transakcije nakon preračunavanja valute i
5. datum valute terećenja ili datum primitka naloga za plaćanje.
(2) Okvirni ugovor mora sadržavati odredbu da platitelj može zahtijevati da mu se informacije iz stavka 1. daju ili čine raspoloživima periodično, najmanje jednom mjesečno, bez naknade te na ugovoreni način kojim se platitelju omogućuju pohrana i reprodukcija informacija u nepromijenjenom obliku.
(3) Pružatelj platnih usluga dužan je na zahtjev platitelja dostaviti informacije iz stavka 1. ovoga članka u papirnatom obliku jednom mjesečno bez naplate naknade platitelju za tu uslugu.“
Navedeno je preuzeto iz Direktive Europske Unije o platnim uslugama na unutarnjem tržištu, DIREKTIVA (EU) 2015/2366 (eng. Revised Directive on Payment Services, PSD2 direktiva), članak 57. stavak 2.6: Okvirni ugovor sadržava uvjet prema kojem platitelj može zahtijevati da se informacije iz stavka 1. daju ili učine raspoloživima periodično najmanje jednom mjesečno, bez naknade te na dogovoreni način kojim se platitelju omogućuje pohrana i reprodukcija informacija u nepromijenjenom obliku.
Očekivalo se i očekuje da članice Europske Unije svojim zakonima prihvate naloge iz Direktive 2015/2366.
6. Zaključak
Omogućavanje mjesečnog izvještaja transakcija i stanja računa bankovnom klijentu sigurno je preko klijentskih portala kojima klijent pristupa preko više-faktorske autentifikacije. Uzimajući u obzir zahtjeve važećeg Zakona o platnom prometu, koji preuzima nalog Direktive Europske Unije o platnim uslugama na unutarnjem tržištu, dobro je rješenje da je izvješće (izvod) u pdf obliku. Taj je oblik nepromjenjiv, a korisnik ga može skinuti u tom obliku ako mu je potreban. Klijentski portal treba biti kriptiran od pošiljatelja, preko poslužitelja, do klijenta (end-to-end) kako bi se izbjegle povrede podataka osjetljivih financijskih podataka.
Matea Marić, specijalist za usklađenost i službenik za zaštitu podataka
IZVORI
^ 1 https://ico.org.uk/action-weve-taken/complaints-and-concerns-data-sets/data-security-incident-trends/glossary-of-terms/data-type/, pristupano 31.5.2026.
^ 2 https://www.ibm.com/think/topics/data-loss-prevention , pristupano 31.5.2026.
^ 3 https://www.getinboxzero.com/blog/post/email-data-loss-prevention-best-practices, pristupano 31.5.2026.
^ 4 https://www.getinboxzero.com/blog/post/email-data-loss-prevention-best-practices, pristupano 31.5.2026.
^ 5 https://www.moxo.com/blog/gdpr-compliant-client-portal, pristupano 1.6.2026.
^ 6 https://eur-lex.europa.eu/legal-content/HR/TXT/PDF/?uri=CELEX:32015L2366, pristupano 2.6.2026.