API ของ open banking
Open banking: ข้อมูลบัญชีและการชำระเงินผ่าน API ของธนาคาร
ข้อมูลบัญชีและการเริ่มการชำระเงินผ่าน API ธนาคารที่อยู่ภายใต้การกำกับดูแลและผู้รวบรวมข้อมูล พร้อมการจัดการความยินยอมและโทเคน
พิมพ์เขียว
เลื่อนแนวนอนเพื่อดูภาพทั้งภาพ
Open banking: ข้อมูลและการชำระเงินด้วยความยินยอมของลูกค้า
ลูกค้าให้ความยินยอม ตัวเชื่อมถือโทเคน และทุกการเรียกไปยังธนาคารได้รับอนุญาตและบันทึกไว้ เมื่อความยินยอมหมดอายุหรือถูกถอน แอปจะถามลูกค้าอีกครั้งแทนที่จะล้มเหลวอย่างเงียบๆ
- เส้นทางหลัก
- แบบอะซิงโครนัส
- เส้นทางข้อยกเว้น
ขั้นตอนการทำงาน 7 ขั้นตอน
ขั้นตอนการทำงานทีละขั้น
- จาก ลูกค้า ไปยัง แอปหรือแพลตฟอร์มของคุณ: ให้ความยินยอม (เส้นทางหลัก)
- จาก แอปหรือแพลตฟอร์มของคุณ ไปยัง ตัวเชื่อม open banking: คำขอบัญชีและการชำระเงิน ผ่าน REST/JSON (เส้นทางหลัก)
- จาก ตัวเชื่อม open banking ไปยัง API ธนาคารหรือผู้รวบรวมข้อมูล: การเรียก API ที่ได้รับอนุญาต ผ่าน OAuth 2.0 · FAPI · REST (เส้นทางหลัก)
- จาก API ธนาคารหรือผู้รวบรวมข้อมูล ไปยัง ตัวเชื่อม open banking: ยอดคงเหลือ ธุรกรรม และสถานะการชำระเงิน ผ่าน REST/JSON · webhook (แบบอะซิงโครนัส)
- จาก ตัวเชื่อม open banking ไปยัง ERP หรือบัญชีแยกประเภท: ธุรกรรมที่ปรับเป็นมาตรฐานแล้ว ผ่าน REST/JSON (เส้นทางหลัก)
- จาก API ธนาคารหรือผู้รวบรวมข้อมูล ไปยัง ตัวเชื่อม open banking: ความยินยอมหมดอายุหรือถูกถอน ผ่าน HTTP 401 · 403 (เส้นทางข้อยกเว้น)
- จาก ตัวเชื่อม open banking ไปยัง แอปหรือแพลตฟอร์มของคุณ: ขอให้ลูกค้าต่ออายุความยินยอม (เส้นทางข้อยกเว้น)
ภาพรวม
Open banking ให้แอปพลิเคชันอ่านบัญชีของลูกค้าและเริ่มการชำระเงินผ่าน API ธนาคารที่อยู่ภายใต้การกำกับดูแล ด้วยความยินยอมของลูกค้า ช่วยขับเคลื่อนการรวบรวมบัญชี การตรวจสอบความสามารถในการผ่อนชำระสำหรับสินเชื่อ หน้าชำระเงินแบบจ่ายผ่านธนาคาร และมุมมองเงินสดข้ามธนาคาร
การออกแบบอ้างอิงวางตัวเชื่อมต่อ open banking ไว้ระหว่างแอปพลิเคชันของคุณกับธนาคาร ทั้งโดยตรงหรือผ่านผู้รวบรวมข้อมูลที่ได้รับใบอนุญาต ตัวเชื่อมต่อดำเนินกระบวนการขอความยินยอม เก็บโทเคนอย่างปลอดภัย เรียก API ของธนาคารตามมาตรฐาน เช่น Berlin Group NextGenPSD2 หรือ UK Open Banking Standard และแปลงข้อมูลของแต่ละธนาคารเป็นโมเดลเดียวที่สอดคล้องกัน
ความยินยอมไม่ถาวร และการออกแบบวางแผนรองรับไว้ เมื่อความยินยอมหมดอายุหรือถูกเพิกถอน ลูกค้าจะถูกขอให้ต่ออายุ แทนที่แอปพลิเคชันจะสูญเสียข้อมูลไปอย่างเงียบๆ ทุกการเรียกได้รับอนุญาต บันทึกไว้ และผูกกับความยินยอมที่อนุญาต
กระบวนการ
ลูกค้าให้ความยินยอม
ลูกค้าเลือกธนาคาร เห็นว่ามีการแบ่งปันข้อมูลใดและนานเท่าใด และยืนยันตัวตนกับธนาคาร ซึ่งจะเปลี่ยนเส้นทางกลับไปยังแอปพลิเคชันของคุณ
แอปพลิเคชันของคุณร้องขอ
แอปพลิเคชันของคุณขอยอดคงเหลือ ธุรกรรม หรือการชำระเงินผ่าน API ของตัวเชื่อมต่อ ไม่ใช่ผ่านธนาคารโดยตรง
ตัวเชื่อมต่อเรียกธนาคาร
ตัวเชื่อมต่อใช้โทเคนที่เก็บไว้เพื่อเรียก API ของธนาคารหรือผู้รวบรวมข้อมูลอย่างได้รับอนุญาต ตามโปรไฟล์ความปลอดภัยที่ธนาคารกำหนด
ข้อมูลและสถานะกลับมา
ยอดคงเหลือ ธุรกรรม และสถานะการชำระเงินกลับมาเป็นคำตอบหรือ webhook และตัวเชื่อมต่อปรับให้เป็นโมเดลเดียวข้ามธนาคาร
ใช้ข้อมูล
ธุรกรรมที่ปรับรูปแบบแล้วป้อนผลิตภัณฑ์ของคุณ โมเดลความเสี่ยง หรือ ERP ของคุณสำหรับสถานะเงินสดและการกระทบยอด
เมื่อระบบเกิดข้อขัดข้อง
ความยินยอมหมดอายุหรือถูกเพิกถอน
ธนาคารปฏิเสธการเรียก ตัวเชื่อมต่อทำเครื่องหมายว่าความยินยอมไม่ถูกต้องอีกต่อไป และแอปพลิเคชันของคุณขอให้ลูกค้าต่ออายุพร้อมอธิบายเหตุผล
การชำระเงินถูกปฏิเสธ
สถานะและเหตุผลของธนาคารกลับมาผ่าน API หรือ webhook และลูกค้ากับทีมปฏิบัติการของคุณเห็นผลลัพธ์ทันที
ธนาคารจำกัดการเข้าถึง
ธนาคารจำกัดความถี่ในการดึงข้อมูลเมื่อไม่มีลูกค้าอยู่ ตัวเชื่อมต่อจัดตารางการรีเฟรชภายในขีดจำกัดเหล่านั้น และถอยออกเมื่อธนาคารส่งสัญญาณ
API ของธนาคารไม่พร้อมใช้งาน
การเรียกถูกลองใหม่ด้วยระยะเวลาที่เพิ่มขึ้น แสดงข้อมูลที่ดีล่าสุดพร้อมอายุของข้อมูล และแจ้งเตือนหากการหยุดให้บริการยังคงต่อเนื่อง
มาตรฐานและระบบ
- มาตรฐานและช่องทางธนาคาร
- PSD2
- Berlin Group NextGenPSD2
- UK Open Banking Standard
- FAPI
- การเชื่อมต่อ
- REST
- Webhooks
- ตัวตนและการเข้าถึง
- OAuth 2.0
- OpenID Connect
คำถามและคำตอบ
เราควรเชื่อมต่อกับธนาคารโดยตรงหรือผ่านผู้รวบรวมข้อมูล
ผู้รวบรวมข้อมูลให้คุณเข้าถึงธนาคารหลายแห่งผ่าน API เดียวและจัดการความแตกต่างของแต่ละธนาคาร ด้วยต้นทุนต่อการเรียกหรือต่อการเชื่อมต่อ การเชื่อมต่อโดยตรงให้การควบคุมมากกว่าและเหมาะกับธนาคารสำคัญจำนวนไม่มาก ผลิตภัณฑ์จำนวนมากเริ่มจากผู้รวบรวมข้อมูลและเพิ่มการเชื่อมต่อโดยตรงภายหลัง เราเปรียบเทียบทางเลือกเทียบกับธนาคารและประเทศที่คุณต้องการ
เราต้องมีใบอนุญาตเพื่อใช้ open banking หรือไม่
ข้อมูลบัญชีและการเริ่มการชำระเงินเป็นกิจกรรมที่อยู่ภายใต้การกำกับดูแลในหลายประเทศ บริษัทของคุณต้องถือใบอนุญาต หรือคุณทำงานผ่านผู้ให้บริการที่ได้รับใบอนุญาตซึ่งถือไว้ กรณีใดใช้ขึ้นอยู่กับประเทศและกรณีใช้งานของคุณ และที่ปรึกษาด้านกฎหมายและการปฏิบัติตามกฎของคุณควรยืนยัน เราสร้างการเชื่อมต่อตามเส้นทางที่คุณเลือก
ความยินยอมของลูกค้าถูกจัดการอย่างไร
ลูกค้าเห็นว่ามีการแบ่งปันข้อมูลใด เพื่อวัตถุประสงค์ใด และนานเท่าใด และยืนยันตัวตนกับธนาคารของตัวเอง ตัวเชื่อมต่อเก็บความยินยอมและโทเคนแบบเข้ารหัส และทุกการเรียกผูกกับความยินยอมที่ยังมีผล ลูกค้าเพิกถอนความยินยอมได้ และตัวเชื่อมต่อจะหยุดเรียกธนาคารนั้นแทนพวกเขาเมื่อเพิกถอน
ครอบคลุมธนาคารและประเทศใดบ้าง
ความครอบคลุมขึ้นอยู่กับกฎของภูมิภาคและ API ของธนาคาร สหภาพยุโรปและสหราชอาณาจักรมีความครอบคลุมกว้างภายใต้ PSD2 และ UK Open Banking Standard ที่อื่นความครอบคลุมแตกต่างกัน และผู้รวบรวมข้อมูลช่วยเติมช่องว่างบางส่วน เราตรวจสอบความครอบคลุมสำหรับธนาคารที่ลูกค้าของคุณใช้ก่อนคุณผูกพันกับการออกแบบ
open banking แทนที่การเชื่อมต่อธนาคารแบบ host-to-host หรือไม่
ไม่แทนสำหรับงานบริหารเงินสดขององค์กรส่วนใหญ่ ช่องทาง host-to-host รองรับไฟล์การชำระเงินจำนวนมากและใบแจ้งยอดแบบเต็มสำหรับบัญชีของคุณเอง Open banking เหมาะกับผลิตภัณฑ์สำหรับลูกค้า ยอดคงเหลือแบบเรียลไทม์ และการชำระเงินรายการเดียว ธุรกิจจำนวนมากใช้ทั้งสองแบบ คือ host-to-host สำหรับรอบการจ่ายเงินของตัวเอง และ open banking สำหรับลูกค้าของตน
ข้อมูล open banking ถูกปกป้องอย่างไร
โทเคนและบันทึกความยินยอมถูกเข้ารหัสเมื่อจัดเก็บ มีเพียงตัวเชื่อมต่อที่ใช้งานได้ และทุกการเรียกถูกบันทึกพร้อมความยินยอมเบื้องหลัง เราเก็บเฉพาะข้อมูลที่วัตถุประสงค์ต้องใช้และกำหนดระยะเวลาเก็บรักษา กฎคุ้มครองข้อมูล เช่น GDPR ใช้กับข้อมูลนี้ และเราออกแบบร่วมกับเจ้าหน้าที่คุ้มครองข้อมูลของคุณ
เริ่มต้นด้วยการพูดคุย ไม่ใช่สัญญา
บอกเราว่าคุณต้องการสร้าง เชื่อมต่อ หรือรักษาความปลอดภัยอะไร สถาปนิกจะพิจารณาร่วมกับคุณ แล้วแนะนำว่าควรเริ่มที่ใด
ขั้นตอนถัดไป
การนัดหมายเวลา
ทีมของเราส่งอีเมลถึงคุณเพื่อนัดหมายเวลาสำหรับการปรึกษา
การปรึกษาก่อนเริ่มงาน
การปรึกษาก่อนเริ่มงานออนไลน์ฟรี 30 นาที: เราพูดคุยถึงเป้าหมาย ระบบ และข้อจำกัดของคุณ
การทบทวนความพร้อม
ในการทบทวนความพร้อมฟรี 48 ชั่วโมง สถาปนิกหลักจะตรวจสอบโครงการของคุณเทียบกับนิยามของความพร้อม 6 ข้อ และแนะนำแนวทางที่เหมาะที่สุด
การเลือกแนวทาง
โครงการที่ขอบเขตพร้อมจะได้รับข้อเสนอที่มีผลผูกพัน ภายใน 3 ถึง 5 วันทำการ โครงการในระยะแนวคิดจะเริ่มใน Blueprint Studio ระบบที่ใช้งานอยู่แต่มีปัญหา ไม่มีเอกสาร หรือต้องเชื่อมต่อ จะเริ่มด้วยการวินิจฉัยระยะเวลา 1 ถึง 2 สัปดาห์ Blueprint Studio และการวินิจฉัยต่างมีค่าธรรมเนียมคงที่ ซึ่งระบุไว้ในข้อเสนอ