ทั้งการดึงข้อมูลจากหน้าจอและการเข้าถึงที่อาศัย Application Programming Interface (API) ต่างก็ช่วยให้ธุรกิจได้รับข้อมูลทางการเงินที่จำเป็นจากบัญชีธนาคารของลูกค้า แต่ใช้กลไกที่แตกต่างกันโดยพื้นฐานในการดำเนินการ การดึงข้อมูลจากหน้าจอจะเข้าสู่ระบบบัญชีธนาคารด้วยข้อมูลเข้าสู่ระบบของคุณ และอ่านข้อมูลจากหน้าเดียวกันกับที่คุณเห็นด้วยตัวเอง การเข้าถึงด้วย API จะกำหนดเส้นทางให้คุณผ่านการเข้าสู่ระบบธนาคารของคุณเอง จากนั้นจะออกโทเค็นที่มีขอบเขตและเพิกถอนได้โดยไม่แตะต้องรหัสผ่านของคุณเลย ในบางกรณี การเชื่อมต่อด้วย API ได้เพิ่มอัตราความสำเร็จสูงถึง 99.9% นอกจากความน่าเชื่อถือแล้ว วิธีนี้ยังมีระดับความปลอดภัยสูง สามารถปรับปรุงประสบการณ์ของผู้ใช้ และช่วยให้ธุรกิจปฏิบัติตามกฎระเบียบได้

ด้านล่างนี้ เราจะสำรวจว่าการดึงข้อมูลจากหน้าจอและการเข้าถึงด้วย API ทำงานอย่างไร เหตุใดการจัดเก็บข้อมูลเข้าสู่ระบบจึงสร้างโปรไฟล์ความเสี่ยงที่แตกต่างจากการเข้าถึงโดยใช้โทเค็น และการที่ธนาคารและหน่วยงานกำกับดูแลกำลังเร่งเปลี่ยนไปใช้ API อย่างไร

ประเด็นสำคัญ

• การดึงข้อมูลจากหน้าจอแบบดั้งเดิมจำเป็นต้องจัดเก็บข้อมูลเข้าสู่ระบบสำหรับบริการธนาคารของลูกค้าไว้ ในขณะที่การเข้าถึงด้วย API อาศัยโทเค็นที่มีขอบเขตและเพิกถอนได้ซึ่งออกให้หลังจากที่ลูกค้าตรวจสอบสิทธิ์กับธนาคารโดยตรงแล้ว

• การดึงข้อมูลจากหน้าจออาจใช้งานไม่ได้เมื่อธนาคารเปลี่ยนแปลงเว็บไซต์ ในขณะที่ API จะส่งคืนข้อมูลที่มีโครงสร้างผ่านสัญญาซึ่งโดยทั่วไปจะเปลี่ยนแปลงก็ต่อเมื่อธนาคารจงใจอัปเดตเท่านั้น

• กฎหมวด 1033 ของ Consumer Financial Protection Bureau (CFPB) และเฟรมเวิร์ก Open Banking ที่มีอยู่ในสหราชอาณาจักรและสหภาพยุโรปกำลังผลักดันให้ธนาคารเปลี่ยนไปใช้การเข้าถึงที่มีมาตรฐาน ซึ่งมักจะหมายถึง API และเลิกใช้การดึงข้อมูลที่อาศัยข้อมูลเข้าสู่ระบบ

การดึงข้อมูลจากหน้าจอในบริการทางการเงินคืออะไร

การดึงข้อมูลจากหน้าจอหมายถึงบริการของบุคคลที่สามเข้าสู่ระบบบัญชีธนาคารของคุณด้วยชื่อผู้ใช้และรหัสผ่านของคุณ จากนั้นจะอ่านข้อมูลตรงจากหน้าเว็บที่ธนาคารแสดงเมื่อคุณเข้าสู่ระบบด้วยตัวเอง โดยไม่มีช่องทางข้อมูลเฉพาะ บริการจะใช้เซสชันเดียวกับที่ลูกค้าใช้ และดึงยอดคงเหลือในบัญชี ประวัติธุรกรรม และหมายเลขบัญชีโดยตรงจากหน้าที่มีการแสดงผล

API ข้อมูลทางการเงินทำงานอย่างไร

การเข้าถึงที่ใช้ API จะเข้ามาแทนที่การแชร์ข้อมูลเข้าสู่ระบบด้วยการส่งมอบที่ได้รับอนุญาต และมักจะทำงานบน Open Authorization (OAuth) 2.0 ซึ่งเป็นมาตรฐานโดยพฤตินัยสำหรับการอนุมัติออนไลน์

ขั้นตอนดังกล่าวแบ่งออกเป็นไม่กี่ขั้นตอนดังต่อไปนี้

• การเปลี่ยนเส้นทางและการตรวจสอบสิทธิ์: ระบบจะส่งคุณไปยังหน้าเข้าสู่ระบบของธนาคารโดยตรง ซึ่งคุณจะป้อนข้อมูลเข้าสู่ระบบที่มีเพียงธนาคารของคุณเท่านั้นที่เห็น

• การยินยอมและขอบเขต: ธนาคารขอให้คุณอนุมัติสิทธิ์แบบจำกัด เช่น ยอดคงเหลือในบัญชีหรือประวัติธุรกรรมที่ธุรกิจที่ร้องขอมีสิทธิ์ดู แทนที่จะให้สิทธิ์การเข้าถึงแบบครอบคลุมกับทุกอย่างในบัญชีของคุณ

• การออกโทเค็น: เมื่อคุณอนุมัติ ธนาคารของคุณจะออกโทเค็นการเข้าถึงให้กับธุรกิจที่ร้องขอ โทเค็นดังกล่าวแสดงถึงการอนุญาตแบบจำกัดที่เพิกถอนได้

• การส่งมอบข้อมูลที่มีโครงสร้าง: ธุรกิจจะเรียกใช้ API ของธนาคารด้วยโทเค็นดังกล่าว และได้รับข้อมูลที่มีโครงสร้างและสมบูรณ์ เช่น JavaScript Object Notation (JSON) กลับมา

เหตุใด API จึงลดความเสี่ยงด้านความปลอดภัยเมื่อเทียบกับการดึงข้อมูลจากหน้าจอ

การดึงข้อมูลจากหน้าจอและการเข้าถึงด้วย API แตกต่างกันอย่างชัดเจนที่สุดในเรื่องของสิ่งที่จัดเก็บไว้และผู้ที่ควบคุมการเข้าถึง ความแตกต่างดังกล่าวกำหนดผลลัพธ์ด้านความปลอดภัยที่ตามมาแทบทุกประการ ตั้งแต่ความเสี่ยงที่จะเกิดการละเมิดไปจนถึงความรวดเร็วในการปิดการเชื่อมต่อที่ถูกบุกรุก

การจัดเก็บข้อมูลเข้าสู่ระบบกับการออกโทเค็น

โดยทั่วไปการดึงข้อมูลจากหน้าจอแบบดั้งเดิมจะกำหนดให้ผู้รวบรวมข้อมูลต้องจัดเก็บชื่อผู้ใช้และรหัสผ่านสำหรับบริการธนาคารที่แท้จริงของคุณไว้ที่ใดที่หนึ่งในระบบของตน ซึ่งมักจะเป็นระยะเวลาตราบเท่าที่คุณยังคงใช้บริการ ชุดข้อมูลเข้าสู่ระบบที่จัดเก็บไว้ทุกชุดคือเป้าหมายหากฐานข้อมูลของผู้รวบรวมข้อมูลรายนั้นถูกละเมิด

สำหรับ API โทเค็นการเข้าถึงที่ส่งต่อไปยังธุรกิจหลังจากการตรวจสอบสิทธิ์ OAuth คือข้อมูลเข้าสู่ระบบที่มีขอบเขตและเพิกถอนได้ ซึ่งมักจะหมดอายุและให้สิทธิ์เข้าถึงเฉพาะสิ่งที่คุณอนุมัติเท่านั้น เช่น การดูประวัติธุรกรรมแบบอ่านอย่างเดียว หากระบบของธุรกิจถูกบุกรุก ธนาคารจะปิดโทเค็นได้โดยไม่ต้องให้คุณรีเซ็ตรหัสผ่าน

การเข้าถึงแบบเต็มรูปแบบกับการเข้าถึงที่กำหนด

รหัสผ่านที่จัดเก็บไว้จะให้สิทธิ์ใครก็ตามที่ถือรหัสดังกล่าวให้มีสิทธิ์เข้าถึงในวงกว้างเช่นเดียวกับที่คุณเข้าสู่ระบบด้วยตนเอง โทเค็นสามารถจำกัดให้ใช้งานได้เพียงฟังก์ชันเดียวเท่านั้น ดังนั้นธุรกิจที่ยืนยันยอดคงเหลือในบัญชีของคุณเพื่อใช้เป็นใบสมัครใช้งานสินเชื่อจะไม่ได้รับประวัติธุรกรรมย้อนหลัง 5 ปีซึ่งไม่จำเป็นต้องใช้เลย ช่องว่างระหว่างการเข้าถึงอย่างสมบูรณ์กับการเข้าถึงที่กำหนดเป็นเหตุผลหนึ่งที่ธนาคาร หน่วยงานกำกับดูแล และผู้ให้บริการ API มองว่าการจัดเก็บข้อมูลเข้าสู่ระบบเป็นรูปแบบที่มีความเสี่ยงสูงกว่า

ความน่าเชื่อถือและความสามารถในการขยายระหว่างการดึงข้อมูลจากหน้าจอกับ API แตกต่างกันอย่างไร

การดึงข้อมูลจากหน้าจอนั้นเปราะบางโดยการออกแบบเนื่องจากต้องพึ่งพาเว็บไซต์ของธนาคารเอง เมื่อธนาคารอัปเดตขั้นตอนการเข้าสู่ระบบ ออกแบบแดชบอร์ดใหม่ หรือเพิ่มขั้นตอนการตรวจสอบสิทธิ์ใหม่ เครื่องมือดึงข้อมูลที่สร้างขึ้นบนเค้าโครงเดิมอาจหยุดทำงานจนกว่าวิศวกรจะสร้างใหม่ด้วยตนเอง ความเปราะบางดังกล่าวบวกกับปัญหาด้านการปรับขนาดที่เกิดขึ้นส่งผลให้เกิดปัญหาที่แตกต่างกันบางประการดังต่อไปนี้

• การพึ่งพาเว็บไซต์: เครื่องมือดึงข้อมูลอาศัย HTML ของธนาคารที่คงที่ ซึ่งหมายความว่าการออกแบบใหม่เป็นประจำอาจทำให้การเชื่อมต่อใช้งานไม่ได้โดยไม่มีการเตือนไปยังผู้รวบรวมข้อมูล

• การบำรุงรักษาด้วยตนเอง: เครื่องมือดึงข้อมูลที่ใช้งานไม่ได้มักจะต้องการวิศวกรมาสร้างใหม่สำหรับเค้าโครงใหม่ ซึ่งเป็นงานที่ต้องทำซ้ำๆ กับธนาคารหลายพันแห่งตามกำหนดการเผยแพร่ของตนเอง

• อัตราความล้มเหลวที่สูงขึ้น: การเชื่อมต่อที่อาศัยการดึงข้อมูลมีแนวโน้มที่จะล้มเหลวในอัตราที่สูงกว่าการเชื่อมต่อที่ใช้ API อย่างมีนัยสำคัญ โดยเฉพาะอย่างยิ่งหลังจากที่ธนาคารเพิ่งเปิดตัวการอัปเดตเว็บไซต์

โดยทั่วไป API จะถือว่ามีความน่าเชื่อถือมากกว่าด้วยเหตุผลบางประการดังต่อไปนี้

• สัญญาข้อมูลที่กำหนดไว้: API ของธนาคารจะส่งคืนข้อมูลบัญชีในโครงสร้างแบบคงที่ เช่น ฟิลด์ยอดคงเหลือที่จัดรูปแบบเป็นจำนวนเต็มในสกุลเงินเซ็นต์ และโดยทั่วไปแล้วโครงสร้างดังกล่าวจะไม่เปลี่ยนแปลงเว้นแต่ธนาคารจะจงใจอัปเดต API และแจ้งให้ทราบ

• การจัดการข้อผิดพลาดที่ชัดเจน: API จะส่งคืนรหัสข้อผิดพลาดที่ชัดเจนเมื่อมีสิ่งใดใช้งานไม่ได้ เพื่อให้ระบบของธุรกิจทราบว่าควรลองใหม่หรือตั้งค่าสถานะปัญหาแทนที่จะต้องทำงานกับข้อมูลที่เสียหายหรือผิดรูปแบบ

• ระดับเครือข่ายกับระดับเชิงเส้น: โครงสร้างพื้นฐานของ Open banking ช่วยอำนวยความสะดวกในการสร้างความสัมพันธ์โดยตรงกับธนาคารและเครดิตยูเนี่ยนหลายพันแห่ง ซึ่งหมายความว่าธุรกิจที่ผสานการทำงานเพียงครั้งเดียวก็เข้าถึงเครือข่ายนั้นได้ทั้งหมด อย่างไรก็ตาม แนวทางที่อาศัยการดึงข้อมูลจำเป็นต้องมีการสร้างและรักษาสคริปต์ที่กำหนดเองสำหรับธนาคารทุกแห่งในรายการ

การดึงข้อมูลจากหน้าจอส่งผลต่อประสบการณ์ของผู้ใช้และความมั่นใจของลูกค้าอย่างไร

การมอบชื่อผู้ใช้และรหัสผ่านสำหรับบริการธนาคารของคุณให้กับแอปของบุคคลที่สามจำเป็นต้องใช้ความไว้วางใจในระดับที่หลายคนไม่สะดวกใจที่จะให้ ข้อความด้านความปลอดภัยของธนาคารหลายแห่งมักฝึกให้ผู้ใช้ไม่แชร์ข้อมูลเข้าสู่ระบบนอกเว็บไซต์ของธนาคาร ดังนั้นแอปที่อาศัยการดึงข้อมูลหน้าจอซึ่งขอให้ผู้ใช้ทำเช่นนั้นในอินเทอร์เฟซของตนจึงอาจถูกมองด้วยความสงสัย ความไม่สอดคล้องกันดังกล่าวอาจทำให้เกิดความลังเลเมื่อถึงขั้นตอนการเชื่อมต่อบัญชี ซึ่งทำให้ผู้ใช้ไม่ดำเนินการตามขั้นตอนการลิงก์จนเสร็จสมบูรณ์ หรือทำให้พวกเขายกเลิกกลางคันเมื่อรู้สึกว่าคำขอข้อมูลเข้าสู่ระบบดูไม่ชอบมาพากล

ขั้นตอนที่อาศัย OAuth จะหลีกเลี่ยงปัญหานั้นได้ เนื่องจากคุณจะพิมพ์รหัสผ่านของคุณในหน้าเข้าสู่ระบบของธนาคารของคุณเองเท่านั้น ซึ่งเป็นอินเทอร์เฟซที่คุ้นเคยในโดเมนที่รู้จัก และหน้าจอขออนุญาตจะบอกคุณโดยเฉพาะเจาะจงว่าคุณยินยอมที่จะแชร์อะไร ความเฉพาะเจาะจงนั้นเปลี่ยนหลักจิตวิทยาของการยินยอม เนื่องจากระบบจะแสดงรายการที่เป็นรูปธรรมให้คุณ เช่น ยอดคงเหลือในบัญชีและประวัติธุรกรรมในช่วง 90 วันที่ผ่านมา และขอให้คุณอนุมัติหรือปฏิเสธโดยตรง ด้วยเหตุนี้ ขั้นตอนการยินยอมที่สร้างขึ้นจากการตรวจสอบสิทธิ์กับธนาคารโดยตรงจึงทำให้มีอัตราการดำเนินการเสร็จสมบูรณ์สูงกว่าการรวบรวมข้อมูลที่อาศัยข้อมูลเข้าสู่ระบบ

เมื่อความมั่นใจสั่นคลอนจากประสบการณ์ที่ไม่ดีหรือพาดหัวข่าวเกี่ยวกับการละเมิดที่ผู้รวบรวมข้อมูลซึ่งอาศัยการดึงข้อมูลจากหน้าจอ การจะเรียกคืนความไว้วางใจจึงเป็นเรื่องยาก ธุรกิจที่สร้างผลิตภัณฑ์ทางการเงินเริ่มมองว่าวิธีการตรวจสอบสิทธิ์เป็นตัวบ่งชี้ความน่าเชื่อถือมากกว่าจะเป็นเพียงรายละเอียดการใช้งานทั่วไป

หน่วยงานกำกับดูแลกำลังผลักดันการเปลี่ยนจากการดึงข้อมูลจากหน้าจอไปเป็น API อย่างไร

กฎหมวด 1033 ของ CFPB ซึ่งปัจจุบันหยุดชะงักลงหลังจากที่ศาลรัฐบาลกลางออกคำสั่งคุ้มครองชั่วคราว พยายามที่จะบังคับใช้หมวดหนึ่งของ Dodd-Frank Act ที่กำหนดให้ผู้ให้บริการข้อมูล เช่น ธนาคาร ต้องทำให้ข้อมูลทางการเงินของลูกค้าพร้อมใช้งานสำหรับบุคคลที่สามตามคำสั่งของลูกค้า เจตนาของกฎนี้คือการให้สิทธิ์ทางกฎหมายแก่ลูกค้าในข้อมูลของตนเองในรูปแบบที่ใช้งานและพกพาได้ กฎดังกล่าวสนับสนุนวิธีการโอนทางอิเล็กทรอนิกส์ที่มีมาตรฐานและปลอดภัยอย่างชัดเจน ซึ่งในทางปฏิบัติมักหมายถึง API มากกว่าการดึงข้อมูลที่อาศัยข้อมูลเข้าสู่ระบบ

สถาบันการเงินขนาดใหญ่หลายแห่งได้ใช้เวลาหลายปีในการสร้างโครงสร้างพื้นฐาน API โดยเฉพาะ ส่วนหนึ่งเพื่อที่จะได้หยุดรองรับการรับส่งข้อมูลของเครื่องมือดึงข้อมูลที่เข้าถึงเว็บไซต์สำหรับลูกค้าของตน ซึ่งอาจทำให้เซิร์ฟเวอร์ทำงานหนักเกินไปและสร้างความยุ่งยากในการตรวจสอบความปลอดภัย เฟรมเวิร์ก Open Banking ในสหราชอาณาจักรและสหภาพยุโรปได้สร้างแบบแผนไว้ก่อนหน้านี้แล้วสำหรับการเปลี่ยนแปลงนี้

เนื่องจากสถาบันและเครดิตยูเนี่ยนขนาดเล็กหลายแห่งยังคงขาดโครงสร้างพื้นฐาน API ที่ธนาคารขนาดใหญ่ได้สร้างไว้แล้ว ผู้รวบรวมข้อมูลบางรายจึงยังคงใช้การดึงข้อมูลเป็นแผนสำรองสำหรับบัญชีที่ยังไม่มีทางเลือก API อย่างไรก็ตาม เมื่อการบังคับใช้หมวด 1033 ดำเนินต่อไปและธนาคารมีตำแหน่งข้อมูล API ที่เป็นไปตามข้อกำหนดมากขึ้น ธุรกิจที่สร้างผลิตภัณฑ์ทางการเงินจึงมีเหตุผลมากที่สุดที่จะต้องดำเนินการตั้งแต่เนิ่นๆ ก่อนที่การเชื่อมต่อที่อาศัยการดึงข้อมูลจะล้าสมัยไป

Stripe Financial Connections ช่วยอะไรได้บ้าง

Stripe Financial Connections คือชุด API ที่ให้คุณสามารถเชื่อมต่อกับบัญชีธนาคารของลูกค้าได้อย่างปลอดภัย และเรียกดูข้อมูลทางการเงินของลูกค้าเหล่านั้น ซึ่งช่วยให้คุณสร้างผลิตภัณฑ์และบริการทางการเงินที่เป็นนวัตกรรมใหม่ได้

Financial Connections สามารถช่วยคุณทำสิ่งต่อไปนี้ได้

• ทำให้กระบวนการเริ่มต้นใช้งานเป็นเรื่องง่าย: นำเสนอขั้นตอนการยืนยันตัวตนบัญชีธนาคารที่ราบรื่นและทันทีที่ไม่ต้องยืนยันตัวตนและบัญชีด้วยตัวเอง

• เข้าถึงข้อมูลทางการเงินที่ครบถ้วน: เรียกดูข้อมูลที่ครอบคลุมเกี่ยวกับบัญชีธนาคารของลูกค้า ทั้งยอดคงเหลือ ธุรกรรม และรายละเอียดบัญชี

• สร้างขั้นตอนการชำระเงินตามแบบแผนล่วงหน้าโดยอัตโนมัติ: ช่วยให้ลูกค้าเชื่อมโยงบัญชีธนาคารสำหรับการชำระเงินตามแบบแผนล่วงหน้าได้อย่างปลอดภัย ซึ่งจะช่วยเพิ่มอัตราการชำระเงินสำเร็จ

• ยกระดับการจัดการความเสี่ยง: วิเคราะห์ข้อมูลทางการเงินของลูกค้าเพื่อทำการตัดสินใจเกี่ยวกับสินเชื่อ การให้กู้ยืม และผลิตภัณฑ์ทางการเงินอื่นๆ อย่างมีข้อมูลมากขึ้น

• ปฏิบัติตามกฎระเบียบ: Financial Connections ช่วยให้คุณปฏิบัติตามข้อกำหนด "รู้จักลูกค้าของคุณ" (KYC) และการต่อต้านการฟอกเงิน (AML)

• สร้างนวัตกรรมด้วยความมั่นใจ: สร้างผลิตภัณฑ์และบริการทางการเงินใหม่ๆ บนโครงสร้างพื้นฐาน Financial Connections ที่ปลอดภัยและเชื่อถือได้

ดูข้อมูลเพิ่มเติมเกี่ยวกับ Financial Connections หรือเริ่มใช้งานเลยวันนี้