Tantangan perbankan bertambah: PSD2 berarti aturan berbagi data baru

Diterbitkan: 2018-04-13

Banyak dari Anda, tidak diragukan lagi, pernah mendengar tentang arahan Otoritas Perbankan Eropa (atau EBA) Uni Eropa yang disebut PSD2 (singkatan dari Payment Services Directive). Pedoman ini awalnya diterbitkan pada akhir tahun 2015. Pada Januari 2018, semua negara anggota diwajibkan untuk menerapkan peraturan tersebut.

Industri perbankan menghadapi banyak tantangan jika mereka belum memikirkan masa depan yang sangat digital.

Memahami Otentikasi Pelanggan yang Kuat untuk PSD2 UE

Tujuan utama PSD2 meliputi:

  1. Membuka peluang pasar baru untuk berbagai pemain seperti pedagang online, sambil menyamakan kedudukan untuk semua pemangku kepentingan utama
  2. Memberikan transparansi konsumen dan pilihan konsumen
  3. Memperkenalkan praktik keamanan baru dan lebih kuat untuk pembayaran online

Ada beberapa pedoman secara umum untuk PSD2; namun, salah satu Pedoman PSD2 yang lebih baik dapat diunduh dari MEF (Mobile Ecosystem Forum).

Otentikasi Pelanggan yang Kuat

Salah satu elemen kunci dari peraturan PSD2 adalah konsep Strong Customer Authentication (atau SCA). EBA mencatat: “Berkat PSD2 konsumen akan lebih terlindungi ketika mereka melakukan pembayaran atau transaksi elektronik (seperti menggunakan perbankan online atau membeli secara online).

Standar Teknis Regulasi (RTS) menjadikan otentikasi pelanggan (SCA) yang kuat sebagai dasar untuk mengakses akun pembayaran seseorang, serta untuk melakukan pembayaran secara online.” Singkatnya SCA meminta, minimal, otentikasi dua faktor (2FA).

Otentikasi dua faktor berarti bahwa pengguna harus "membuktikan" identitas mereka dengan dua elemen terpisah dari tiga:

  1. Sesuatu yang mereka ketahui (kode PIN atau kata sandi)
  2. Sesuatu yang mereka miliki (perangkat seluler, kartu)
  3. Sesuatu itu (sidik jari, pemindaian wajah: misalnya biometrik)

EBA mencatat bahwa SCA umumnya digunakan di seluruh UE; namun, hal ini tidak selalu berlaku untuk transaksi pembayaran online seperti pembayaran kartu kredit atau transfer bank langsung. SCA diterapkan di negara-negara UE Belgia, Belanda, dan Swedia); namun, di negara-negara Uni Eropa lainnya, SCA hanya diterapkan secara sukarela, menurut siaran pers yang sangat baik dari Komisi Eropa.

Sementara negara-negara anggota UE akan menerapkan PSD2 pada Januari 2018, SCA akan menjadi wajib 18 bulan kemudian setelah Standar Teknis Regulasi (RTS) EBA setelah tanggal berlakunya RTS (yang diperkirakan akan terjadi akhir tahun ini) . Jadi intinya, kami melihat pertengahan hingga akhir 2019 (September 2019 adalah salah satu tanggal yang dikutip beberapa dokumen). Ini akan memberikan waktu yang cukup bagi semua pemangku kepentingan untuk memasukkan SCA dan persyaratan keamanan lainnya ke dalam sistem dan alur kerja mereka.

Perbankan ritel: Singa dan bankir dan fintech, astaga!

retail_banking_fintech.jpg Fintech mengancam status quo. Tidak seperti bank, mereka tidak dibebani oleh warisan, peraturan, dan dalam banyak kasus, bahkan kebutuhan untuk menghasilkan uang. Bankir ritel perlu beradaptasi dan fokus pada hubungan pelanggan untuk bersaing.

2FA untuk SCA

Mengingat garis waktu SCA, 2018 adalah waktu yang tepat bagi bisnis untuk mulai menerapkan solusi 2FA untuk memperhitungkan peningkatan keamanan yang diperlukan.

Firma hukum internasional Taylor Wessing, dalam makalah mereka: Otentikasi pelanggan yang kuat di bawah PSD2 , mencatat bahwa “EBA setuju dengan mayoritas responden untuk Makalah Konsultasi bahwa, untuk memastikan netralitas teknologi dan memungkinkan pengembangan yang ramah pengguna , alat pembayaran yang dapat diakses dan inovatif, seharusnya tidak mendefinisikan elemen otentikasi lebih lanjut.” Ini berarti bahwa EBA tidak menentukan cara penerapan 2FA. Ada berbagai skema termasuk pengiriman token melalui saluran seluler seperti SMS atau pemberitahuan push atau saluran email yang lebih tradisional, serta solusi token lunak TOTP dan lainnya.

Semua ini dicatat, kami harus menunjukkan bahwa, seperti skema implementasi 2FA yang baik, ada beberapa batasan dan peraturan khusus dan ini perlu dipertimbangkan dengan hati-hati.

Kode otentikasi

RTS mencatat bahwa pembuatan kode otentikasi memenuhi ketentuan berikut:

  1. Tidak ada informasi mengenai pengetahuan, kepemilikan, dan warisan yang dapat diperoleh dari pengungkapan kode otentikasi
  2. Tidak mungkin membuat kode otentikasi baru berdasarkan pengetahuan tentang kode otentikasi lain yang dibuat sebelumnya
  3. Kode otentikasi tidak dapat dipalsukan

Selain itu, RTS menyatakan bahwa tidak lebih dari 5 upaya autentikasi yang gagal harus dilakukan dalam waktu kode aktif dan bahwa waktu maksimum tanpa aktivitas oleh pembayar atau pengguna setelah diautentikasi untuk mengakses akun pembayarannya secara online tidak boleh melebihi 5 menit. .

Penautan dinamis dari transaksi

RTS menunjukkan bahwa transaksi jarak jauh elektronik – pada dasarnya pembayaran yang dilakukan melalui Internet (baik pada perangkat desktop seperti laptop atau perangkat seluler) harus menyertakan elemen yang “menghubungkan transaksi secara dinamis ke jumlah tertentu dan penerima pembayaran tertentu.” RTS menganggap ini sebagai bentuk tambahan dari SCA.

Untuk persyaratan SCA ini, jumlah transaksi pembayaran serta siapa penerima pembayaran (atau pedagang) harus diberikan kembali kepada pengguna pada saat transaksi 2FA. Jika ada perubahan dalam jumlah atau penerima pembayaran, kode otentikasi lain harus dibuat (misalnya "menghubungkan secara dinamis" kode itu ke penerima pembayaran baru dan/atau jumlah pembayaran). Pesan SMS dengan semua informasi yang diperlukan mungkin terlihat seperti gambar di sebelah kanan: Kode keamanan 10 menit, nama pedagang (atau penerima pembayaran) dan jumlah transaksi.

Menariknya, kode otentikasi yang dihasilkan oleh aplikasi yang sesuai dengan TOTP pihak ketiga seperti Google Authenticator dibuat sepenuhnya terpisah dari informasi pembayaran/pedagang dan oleh karena itu tidak dapat ditautkan secara dinamis.

Independensi saluran

Persyaratan ini agak rumit. RTS menyatakan bahwa “penyedia layanan pembayaran harus mengadopsi langkah-langkah keamanan, di mana salah satu elemen otentikasi pelanggan yang kuat atau kode otentikasi itu sendiri digunakan melalui perangkat multiguna, untuk mengurangi risiko yang akan dihasilkan dari perangkat multiguna tersebut. dikompromikan.” Perangkat multiguna bisa berupa perangkat seluler atau tablet, atau bahkan laptop.

Jika pengguna menggunakan laptop dan diminta untuk melakukan pembayaran, maka pedagang tersebut dapat mengirim SMS ke perangkat seluler pengguna dengan penerima pembayaran (misalnya pedagang) serta jumlah yang akan mereka bayarkan, bersama dengan otentikasi. kode di badan SMS.

Dalam contoh lain, jika pengguna menggunakan perangkat seluler untuk berinteraksi dengan pedagang dan melakukan pembayaran, maka independensi saluran ini tidak secara khusus melarang SMS atau saluran pengiriman khusus seluler apa pun. Di sini, itu adalah garis yang bagus. Dalam banyak kasus, satu-satunya perangkat yang dimiliki pengguna adalah perangkat multiguna seperti ponsel. Tapi, independensi saluran hanya itu – saluran independen pada perangkat yang sama – SMS dengan kode otentikasi adalah saluran yang berbeda (pada kenyataannya, ini adalah saluran out-of-band , dicapai melalui nomor telepon seluler) daripada seluler aplikasi atau browser web yang digunakan pengguna untuk berinteraksi dengan pedagang. Independensi saluran yang sama akan berlaku untuk menggunakan aplikasi seluler untuk menghasilkan kode yang sesuai dengan TOTP (seperti Google Authenticator), tetapi seperti yang disebutkan sebelumnya, kode keluhan TOTP gagal dalam penautan dinamis transaksi.

Sebaliknya, jika pengguna menggunakan aplikasi seluler untuk mengakses pedagang, maka pemberitahuan push ke aplikasi yang sama (dengan kode autentikasi) tidak akan mungkin dilakukan, karena keduanya adalah saluran yang sama.

Ada orang yang akan mengatakan bahwa 2FA melalui SMS sangat tidak aman dan dalam beberapa kasus, itu bisa jadi benar. Ya, ada beberapa contoh terisolasi di mana penyerang berhasil mengakses pesan SMS 2FA melalui SS7 pada satu operator; namun, banyak dari kerentanan ini telah ditutup. Selain itu, sangat penting bagaimana kode otentikasi dihasilkan dan diberikan kepada pengguna dan bagaimana penyedia layanan pesan mengirimkan kode tersebut.

Dalam situasi di mana perangkat multiguna lazim (dan hari ini, ini adalah dan akan terus menjadi perangkat yang paling umum), saluran pesan yang disediakan operator seluler harus terus menjadi saluran out-of-band yang layak untuk token 2FA.

Untuk analisis yang lebih rinci, saya menemukan posting blog informatif oleh Frederik Mennes yang memberikan detail lebih lanjut tentang jenis skenario apa – terutama untuk perangkat multiguna – yang harus sesuai untuk PSD2 SCA.

PSD2 SCA tidak boleh dianggap enteng, tetapi banyak solusi 2FA yang sudah diterapkan seharusnya berhasil; namun, kami juga mengetahui bahwa banyak pedagang online belum memberikan solusi yang sesuai dengan PSD2 SCA. Sampai tulisan ini dibuat, masih ada cukup waktu untuk memasukkan SCA ke dalam alur kerja pembayaran.

SAP Authentication 365 adalah solusi yang menyediakan solusi cloud berbasis API untuk memungkinkan bisnis menerapkan SCA yang sesuai dengan PSD2. Layanan seluler SAP Authentication 365 adalah layanan end-to-end yang memungkinkan Anda untuk menerapkan layanan otentikasi dua faktor (2FA) multisaluran dengan cepat dan aman, dengan otentikasi yang disesuaikan dengan bisnis digital Anda.

Ini membantu melindungi identitas dan data pelanggan perusahaan Anda dengan mengaktifkan otentikasi melalui SMS, email, pemberitahuan push, atau token lunak TOTP. REST API dari SAP menyederhanakan pembuatan dan otentikasi kode validasi atau otentikasi dan memberikan fleksibilitas dan kemampuan untuk memungkinkan penerapan strategi SCA yang sesuai dengan PSD2.