ข้ามไปยังเนื้อหา
XSIS
พื้นที่ลูกค้าขอข้อเสนอ
อาคารสำนักงานสูงในย่านการเงิน

กลุ่มอุตสาหกรรม

ฟินเทคและบริการทางการเงิน

ธนาคาร การชำระเงิน และบัญชีแยกประเภทที่เชื่อมต่อกันเพื่อความแม่นยำแบบเรียลไทม์และการตรวจสอบตามกฎระเบียบ

จองการปรึกษาฟรีขอข้อเสนอ

ทำไมผลิตภัณฑ์ทางการเงินจึงล้มเหลวที่จุดเชื่อมต่อ

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

  • กำหนดเวลากฎระเบียบที่เข้มงวด

    ข้อกำหนดการออกใบแจ้งหนี้อิเล็กทรอนิกส์ เช่น ZATCA ระยะที่ 2 ของซาอุดีอาระเบียและ PINT-AE ของสหรัฐอาหรับเอมิเรตส์ และกฎความยืดหยุ่น เช่น DORA มาถึงในวันที่กำหนดตายตัว

  • ข้อมูลที่ออกนอกประเทศไม่ได้

    ธนาคารที่อยู่ภายใต้กฎระเบียบไม่สามารถส่งข้อมูลลูกค้าหรือข้อมูลทางการเงินไปยังบริการ AI สาธารณะในต่างประเทศได้

  • การกระทบยอดด้วยมือ

    ไฟล์แบบแบตช์และสเปรดชีตยังคงอยู่ระหว่างธนาคาร ผู้ประมวลผล และ ERP

สิ่งที่เปลี่ยนไป

  1. ความแม่นยำของบัญชีแยกประเภทแบบเรียลไทม์

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

  2. พร้อมสำหรับการตรวจสอบตามกฎระเบียบ

    การเข้าถึงจำกัดและบันทึกไว้ และทุกการเปลี่ยนแปลงตรวจสอบย้อนกลับได้ก่อนเปิดใช้งานจริง

  3. AI อธิปไตย

    AI สำหรับเอกสารและผู้ช่วยที่ทำงานภายในสภาพแวดล้อมของคุณเอง โดยไม่มีข้อมูลออกไป

เส้นขอบฟ้าดูไบยามพลบค่ำ มองจากคลองน้ำ

กลุ่มความเชี่ยวชาญหลักของเรา

ฟินเทคคืออุตสาหกรรมหลักของเรา เราสร้างและเชื่อมต่อซอฟต์แวร์ที่ธนาคาร บริษัทชำระเงิน ผู้ให้สินเชื่อ ผู้บริหารความมั่งคั่ง บริษัทประกันภัย และผู้ให้บริการกระเป๋าเงินใช้งาน และเรารู้จักมาตรฐานที่ระบบเหล่านั้นใช้: ISO 20022, ISO 8583, EMV, API ของ open banking และรูปแบบไฟล์ที่ธนาคารยังพึ่งพา

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

พนักงานธนาคารนับเงินสดที่เคาน์เตอร์โดยมีลูกค้าอยู่ด้วย

ขอบเขตการทำงานของเรา

สิ่งที่เราสร้าง

  • แอปและพอร์ทัลธนาคารดิจิทัลสำหรับลูกค้ารายย่อยและธุรกิจ
  • บริการที่ห่อหุ้มและขยายระบบ core banking ผ่าน API แทนการแทนที่
  • ช่องทางองค์กรสำหรับไฟล์การชำระเงิน การอนุมัติ รายการเดินบัญชี และฐานะเงินสด
  • เครื่องมือหลังบ้านสำหรับปฏิบัติการ การสอบสวนการชำระเงิน และการบริการลูกค้า
  • เทคโนโลยีการเงินอิสลามและส่วนขยายบัญชีแยกประเภทหลัก

การเชื่อมต่อระบบทั่วไป

  • ระบบ core banking ผ่าน API คิวข้อความ หรืออินเทอร์เฟซแบบแบตช์

สิ่งที่เราสร้าง

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

สิ่งที่เราสร้าง

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

การเชื่อมต่อระบบทั่วไป

  • สำนักงานข้อมูลเครดิต ข้อมูลบัญชีจาก open banking และการยืนยันตัวตน
  • ระบบ core banking หรือบัญชีแยกประเภทสินเชื่อ และการเรียกเก็บเงินผ่านการหักบัญชีอัตโนมัติหรือบัตร

สิ่งที่เราสร้าง

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

การเชื่อมต่อระบบทั่วไป

  • ผู้ดูแลทรัพย์สิน โบรกเกอร์ และผู้ให้บริการข้อมูลตลาด
  • ระบบจัดการพอร์ตการลงทุนและ CRM

สิ่งที่เราสร้าง

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

การเชื่อมต่อระบบทั่วไป

  • ระบบบริหารกรมธรรม์และระบบเคลม
  • การเรียกเก็บเบี้ยประกัน การคืนเงิน และบัญชีแยกประเภท

สิ่งที่เราสร้าง

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

การเชื่อมต่อระบบทั่วไป

  • ผู้ประมวลผลการออกบัตรและบริการแปลงเป็นโทเคน

สิ่งที่เราสร้าง

  • โมเดลเชิงปริมาณขนาดใหญ่ (LQM) สำหรับการจำลองทางการเงิน
  • ระบบซื้อขายความถี่สูง (HFT)
  • การตรวจจับการฉ้อโกง AML และความผิดปกติทางพฤติกรรมแบบเรียลไทม์

การเชื่อมต่อระบบทั่วไป

  • ผู้ให้บริการข้อมูลตลาดและสถานที่ซื้อขาย

สิ่งที่เราสร้าง เชื่อมต่อ และรักษาความปลอดภัย

  • ช่องทางดิจิทัล

    แอปธนาคาร กระเป๋าเงิน และการลงทุนบนเว็บและมือถือ ออกแบบสำหรับลูกค้าและสร้างรองรับปริมาณวันเงินเดือนออกและสิ้นเดือน

  • ส่วนขยายระบบหลัก

    บริการรอบระบบ core banking หรือบัญชีแยกประเภทที่เพิ่มผลิตภัณฑ์และช่องทางโดยไม่ต้องแทนที่ระบบเดิม

  • การจัดการการชำระเงิน

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

  • การรับลูกค้าใหม่และ KYC

    การรับลูกค้ารายบุคคลและธุรกิจใหม่ด้วยการตรวจสอบตัวตน การคัดกรอง และการเก็บเอกสาร พร้อมเส้นทางที่ชัดเจนสู่การตรวจทานด้วยมือ

  • การเฝ้าระวังการฉ้อโกงและธุรกรรม

    กฎและโมเดลการเรียนรู้ของเครื่องที่ให้คะแนนธุรกรรมขณะเกิดขึ้นและพักรายการที่น่าสงสัยไว้ให้ตรวจทาน

  • การกระทบยอดและการเงิน

    การจับคู่ข้ามบัญชีแยกประเภท ผู้ประมวลผล ธนาคาร และ ERP เพื่อให้ฝ่ายการเงินปิดบัญชีบนข้อมูลที่เชื่อถือได้

  • การเชื่อมต่อธนาคาร

    การชำระเงินและรายการเดินบัญชีในรูปแบบ ISO 20022 และ MT ผ่านช่องทาง host-to-host, EBICS หรือ API ของธนาคาร

  • การประมวลผลบัตร

    ธนาคารผู้รับชำระ ผู้ประมวลผล และแพลตฟอร์มการออกบัตรผ่าน ISO 8583 หรือ API พร้อมเครื่อง EMV ในร้านและ 3-D Secure ออนไลน์

  • Open banking

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

  • ตัวตน KYC และ AML

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

  • ERP และบัญชีแยกประเภท

    รายการบันทึก ค่าธรรมเนียม และการชำระบัญชีที่นำเข้า ERP เพื่อให้ฝ่ายการเงินเห็นตัวเลขเดียวกับฝ่ายปฏิบัติการ

  • ข้อมูลบัตรและ PCI DSS

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

  • การยืนยันตัวตนลูกค้าที่เข้มแข็ง

    เราสร้างขั้นตอนการยืนยันตัวตนที่กฎการชำระเงินและธนาคารกำหนด เช่น การลงชื่อเข้าใช้สองขั้นตอนและการลงนามธุรกรรม โดยใช้เฉพาะข้อยกเว้นที่ทีมความเสี่ยงของคุณอนุญาต

  • การควบคุม KYC และ AML

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

  • การคุ้มครองข้อมูล

    เราตกลงว่าข้อมูลส่วนบุคคลและข้อมูลทางการเงินจะเก็บและประมวลผลที่ใดก่อนเริ่มงาน และออกแบบตาม GDPR และกฎหมายท้องถิ่น เช่น PDPL ของสหรัฐอาหรับเอมิเรตส์และ PDPL ของซาอุดีอาระเบีย เมื่อบังคับใช้

  • ร่องรอยการตรวจสอบและความยืดหยุ่น

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

วิธีการทำงานของเรา

  1. ทบทวนความพร้อม

    วิศวกรหลักทบทวนขอบเขต ระบบ ข้อมูล และความต้องการด้านกฎระเบียบ

  2. ออกแบบจุดเชื่อมต่อ

    ชั้นการเชื่อมต่อ เส้นทางความล้มเหลว และร่องรอยการตรวจสอบได้รับการออกแบบก่อน

  3. ส่งมอบและดำเนินงาน

    การเผยแพร่เวอร์ชันเป็นระยะหลังด่านการตรวจรับ แล้วดำเนินงานแบบจัดการภายใต้ระดับบริการที่ตกลงไว้

ผลิตภัณฑ์ทางการเงินดิจิทัลแบบครบวงจรแอปธนาคารหรือกระเป๋าเงินสื่อสารกับชั้น API เดียว เบื้องหลังมีงานตรวจสอบตัวตน การประมวลผลบัตร และบัญชีแยกประเภทหลัก ธุรกรรมถูกคัดกรองขณะเกิดขึ้น และรายการที่น่าสงสัยถูกพักไว้ให้เจ้าหน้าที่ตรวจทานผู้คนลูกค้าบริการแอปธนาคารหรือกระเป๋าเงินเว็บและมือถือXSISชั้น APIการยืนยันตัวตนขีดจำกัดและบันทึกการตรวจสอบระบบภายนอกผู้ให้บริการ KYCและ AMLการรับลูกค้าใหม่และการคัดกรองเกตเวย์ผู้ประมวลผลบัตรการออกบัตรและการอนุมัติธนาคารระบบธนาคารหลักหรือบัญชีแยกประเภทบัญชี ยอดคงเหลือและรายการบันทึกบริการการเฝ้าระวังการฉ้อโกงและธุรกรรมกฎและโมเดลผู้คนทีมกำกับการปฏิบัติตามกฎและทีมปฏิบัติการทบทวนรายการที่พักไว้และรายการส่งต่อ12REST/JSON · OAuth 2.03REST/JSONwebhook4REST/JSON · ISO 200225REST/JSON6ISO 8583789

ผลิตภัณฑ์ทางการเงินดิจิทัลแบบครบวงจร

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

  • เส้นทางหลัก
  • แบบอะซิงโครนัส
  • เส้นทางข้อยกเว้น
ขั้นตอนการทำงาน 9 ขั้นตอน

ขั้นตอนการทำงานทีละขั้น

  1. จาก ลูกค้า ไปยัง แอปธนาคารหรือกระเป๋าเงิน: สมัคร ชำระเงิน และโอนเงิน (เส้นทางหลัก)
  2. จาก แอปธนาคารหรือกระเป๋าเงิน ไปยัง ชั้น API: คำขอ ผ่าน REST/JSON · OAuth 2.0 (เส้นทางหลัก)
  3. จาก ชั้น API ไปยัง ผู้ให้บริการ KYC และ AML: การตรวจสอบตัวตนและการคัดกรอง ผ่าน REST/JSON · webhook (เส้นทางหลัก)
  4. จาก ชั้น API ไปยัง ระบบธนาคารหลักหรือบัญชีแยกประเภท: รายการบันทึกบัญชีและยอดคงเหลือ ผ่าน REST/JSON · ISO 20022 (เส้นทางหลัก)
  5. จาก ชั้น API ไปยัง ผู้ประมวลผลบัตร: การออกบัตรและการควบคุมบัตร ผ่าน REST/JSON (เส้นทางหลัก)
  6. จาก ผู้ประมวลผลบัตร ไปยัง ระบบธนาคารหลักหรือบัญชีแยกประเภท: ธุรกรรมบัตร ผ่าน ISO 8583 (แบบอะซิงโครนัส)
  7. จาก ชั้น API ไปยัง การเฝ้าระวังการฉ้อโกงและธุรกรรม: ธุรกรรมที่ต้องคัดกรอง เป็นสตรีมอีเวนต์ (แบบอะซิงโครนัส)
  8. จาก การเฝ้าระวังการฉ้อโกงและธุรกรรม ไปยัง ทีมกำกับการปฏิบัติตามกฎและทีมปฏิบัติการ: พักไว้เพื่อตรวจทาน (เส้นทางข้อยกเว้น)
  9. จาก ผู้ให้บริการ KYC และ AML ไปยัง ทีมกำกับการปฏิบัติตามกฎและทีมปฏิบัติการ: การตรวจสอบที่ล้มเหลวหรือไม่ชัดเจนถูกส่งต่อ (เส้นทางข้อยกเว้น)
ERP ถึงธนาคาร: เงินออก รายการเดินบัญชีเข้าการชำระเงินที่อนุมัติแล้วออกจาก ERP เป็นไฟล์ ISO 20022 ที่ลงนามผ่านช่องทาง host-to-host รายงานสถานะและรายการเดินบัญชีกลับมาทางเดียวกันและจับคู่กับรายการค้าง รายการถูกปฏิเสธและรายการที่ไม่ตรงจะส่งถึงทีมของคุณพร้อมเหตุผลERPERPรอบการจ่ายเงินรายการค้างและบัญชีแยกประเภทXSISชั้นการเชื่อมต่อการแปลงข้อมูลการตรวจสอบ การลงนามและการกำหนดเวลาเกตเวย์ช่องทางธนาคารที่ปลอดภัยHost-to-host SFTP,EBICS หรือ APIของธนาคารธนาคารธนาคารการชำระเงินและการบริหารเงินสดบริการกลไกกระทบยอดกฎการจับคู่และช่วงคลาดเคลื่อนที่ยอมรับผู้คนทีมบริหารเงินและการเงินทบทวนรายการถูกปฏิเสธและรายการที่ไม่ตรง1REST/JSON · IDoc2ISO 20022 pain.001OpenPGP3SFTP H2H4pain.002 · camt.053MT9405SFTP H2H6camt.0537REST/JSON8pain.002 RJCT910

ERP ถึงธนาคาร: เงินออก รายการเดินบัญชีเข้า

การชำระเงินที่อนุมัติแล้วออกจาก ERP เป็นไฟล์ ISO 20022 ที่ลงนามผ่านช่องทาง host-to-host รายงานสถานะและรายการเดินบัญชีกลับมาทางเดียวกันและจับคู่กับรายการค้าง รายการถูกปฏิเสธและรายการที่ไม่ตรงจะส่งถึงทีมของคุณพร้อมเหตุผล

  • เส้นทางหลัก
  • แบบอะซิงโครนัส
  • เส้นทางข้อยกเว้น
ขั้นตอนการทำงาน 10 ขั้นตอน

ขั้นตอนการทำงานทีละขั้น

  1. จาก ERP ไปยัง ชั้นการเชื่อมต่อ: รอบการจ่ายเงินที่อนุมัติแล้ว ผ่าน REST/JSON · IDoc (เส้นทางหลัก)
  2. จาก ชั้นการเชื่อมต่อ ไปยัง ช่องทางธนาคารที่ปลอดภัย: ไฟล์การชำระเงินที่ลงนามและเข้ารหัสแล้ว ผ่าน ISO 20022 pain.001 · OpenPGP (เส้นทางหลัก)
  3. จาก ช่องทางธนาคารที่ปลอดภัย ไปยัง ธนาคาร: ส่งถึงธนาคารแล้ว ผ่าน SFTP H2H (เส้นทางหลัก)
  4. จาก ธนาคาร ไปยัง ช่องทางธนาคารที่ปลอดภัย: รายงานสถานะและรายการเดินบัญชี ผ่าน pain.002 · camt.053 · MT940 (แบบอะซิงโครนัส)
  5. จาก ช่องทางธนาคารที่ปลอดภัย ไปยัง ชั้นการเชื่อมต่อ: เก็บรวบรวมและตรวจสอบแล้ว ผ่าน SFTP H2H (แบบอะซิงโครนัส)
  6. จาก ชั้นการเชื่อมต่อ ไปยัง กลไกกระทบยอด: รายการในรายการเดินบัญชี ผ่าน camt.053 (แบบอะซิงโครนัส)
  7. จาก กลไกกระทบยอด ไปยัง ERP: รายการที่จับคู่แล้วบันทึกเข้าบัญชี ผ่าน REST/JSON (เส้นทางหลัก)
  8. จาก ชั้นการเชื่อมต่อ ไปยัง ทีมบริหารเงินและการเงิน: การชำระเงินที่ถูกปฏิเสธ พร้อมรหัสเหตุผล ผ่าน pain.002 RJCT (เส้นทางข้อยกเว้น)
  9. จาก กลไกกระทบยอด ไปยัง ทีมบริหารเงินและการเงิน: รายการที่ไม่ตรง: รายการกระทบยอดที่ไม่ตรง (เส้นทางข้อยกเว้น)
  10. จาก ทีมบริหารเงินและการเงิน ไปยัง ERP: แก้ไขและส่งใหม่แล้ว (เส้นทางข้อยกเว้น)
การชำระเงินด้วยบัตร: อนุมัติที่เคาน์เตอร์ ชำระบัญชีภายหลัง กระทบยอดใน ERPเครื่องหรือหน้าชำระเงินถามเกตเวย์ เกตเวย์ถามธนาคารผู้รับชำระ และธนาคารผู้รับชำระส่งต่อไปยังเครือข่ายบัตรและผู้ออกบัตร ไฟล์ชำระบัญชีมาถึงภายหลังและจับคู่กับยอดขายและค่าธรรมเนียมใน ERP การหมดเวลาทำให้เกิดการกลับรายการ เพื่อไม่ให้ลูกค้าถูกเรียกเก็บซ้ำPOSเครื่อง EMVหรือหน้าชำระเงินออนไลน์ชิป การแตะจ่ายและอีคอมเมิร์ซเกตเวย์เกตเวย์การชำระเงินการแปลงเป็นโทเคนและการกำหนดเส้นทางธนาคารธนาคารผู้รับชำระการอนุมัติและการชำระบัญชีระบบภายนอกเครือข่ายบัตรและผู้ออกบัตรอนุมัติหรือปฏิเสธERPERPยอดขาย ค่าธรรมเนียมและการจ่ายเงินXSISชั้นการเชื่อมต่อการอ่านและจับคู่ไฟล์ชำระบัญชีผู้คนทีมปฏิบัติการชำระเงินรายการไม่ตรงข้อพิพาทและการเรียกคืนเงิน1EMV · REST/JSON2ISO 85833ISO 85834ISO 85835SFTP6REST/JSON7ISO 8583 04008

การชำระเงินด้วยบัตร: อนุมัติที่เคาน์เตอร์ ชำระบัญชีภายหลัง กระทบยอดใน ERP

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

  • เส้นทางหลัก
  • แบบอะซิงโครนัส
  • เส้นทางข้อยกเว้น
ขั้นตอนการทำงาน 8 ขั้นตอน

ขั้นตอนการทำงานทีละขั้น

  1. จาก เครื่อง EMV หรือหน้าชำระเงินออนไลน์ ไปยัง เกตเวย์การชำระเงิน: คำขออนุมัติ ผ่าน EMV · REST/JSON (เส้นทางหลัก)
  2. จาก เกตเวย์การชำระเงิน ไปยัง ธนาคารผู้รับชำระ: การอนุมัติ ผ่าน ISO 8583 (เส้นทางหลัก)
  3. จาก ธนาคารผู้รับชำระ ไปยัง เครือข่ายบัตรและผู้ออกบัตร: ส่งต่อไปยังผู้ออกบัตร ผ่าน ISO 8583 (เส้นทางหลัก)
  4. จาก ธนาคารผู้รับชำระ ไปยัง เกตเวย์การชำระเงิน: อนุมัติหรือปฏิเสธ ผ่าน ISO 8583 (แบบอะซิงโครนัส)
  5. จาก ธนาคารผู้รับชำระ ไปยัง ชั้นการเชื่อมต่อ: ไฟล์ชำระบัญชีและค่าธรรมเนียม ผ่าน SFTP (แบบอะซิงโครนัส)
  6. จาก ชั้นการเชื่อมต่อ ไปยัง ERP: ยอดขาย ค่าธรรมเนียม และการจ่ายเงินที่ชำระบัญชีแล้ว ผ่าน REST/JSON (เส้นทางหลัก)
  7. จาก เกตเวย์การชำระเงิน ไปยัง เครื่อง EMV หรือหน้าชำระเงินออนไลน์: ไม่มีการตอบกลับทันเวลา: กลับรายการอัตโนมัติ ผ่าน ISO 8583 0400 (เส้นทางข้อยกเว้น)
  8. จาก ชั้นการเชื่อมต่อ ไปยัง ทีมปฏิบัติการชำระเงิน: รายการชำระบัญชีไม่ตรงหรือการเรียกคืนเงิน (เส้นทางข้อยกเว้น)
Open banking: ข้อมูลและการชำระเงินด้วยความยินยอมของลูกค้าลูกค้าให้ความยินยอม ตัวเชื่อมถือโทเคน และทุกการเรียกไปยังธนาคารได้รับอนุญาตและบันทึกไว้ เมื่อความยินยอมหมดอายุหรือถูกถอน แอปจะถามลูกค้าอีกครั้งแทนที่จะล้มเหลวอย่างเงียบๆผู้คนลูกค้าบริการแอปหรือแพลตฟอร์มของคุณการบริหารเงินทุนสินเชื่อ หรือบัญชีXSISตัวเชื่อม openbankingความยินยอม โทเคนและการปรับข้อมูลให้เป็นมาตรฐานธนาคารAPIธนาคารหรือผู้รวบรวมข้อมูลข้อมูลบัญชีและการเริ่มต้นการชำระเงินERPERPหรือบัญชีแยกประเภทฐานะเงินสดและการกระทบยอด12REST/JSON3OAuth 2.0 · FAPI · REST4REST/JSON · webhook5REST/JSON6HTTP 401 · 4037

Open banking: ข้อมูลและการชำระเงินด้วยความยินยอมของลูกค้า

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

  • เส้นทางหลัก
  • แบบอะซิงโครนัส
  • เส้นทางข้อยกเว้น
ขั้นตอนการทำงาน 7 ขั้นตอน

ขั้นตอนการทำงานทีละขั้น

  1. จาก ลูกค้า ไปยัง แอปหรือแพลตฟอร์มของคุณ: ให้ความยินยอม (เส้นทางหลัก)
  2. จาก แอปหรือแพลตฟอร์มของคุณ ไปยัง ตัวเชื่อม open banking: คำขอบัญชีและการชำระเงิน ผ่าน REST/JSON (เส้นทางหลัก)
  3. จาก ตัวเชื่อม open banking ไปยัง API ธนาคารหรือผู้รวบรวมข้อมูล: การเรียก API ที่ได้รับอนุญาต ผ่าน OAuth 2.0 · FAPI · REST (เส้นทางหลัก)
  4. จาก API ธนาคารหรือผู้รวบรวมข้อมูล ไปยัง ตัวเชื่อม open banking: ยอดคงเหลือ ธุรกรรม และสถานะการชำระเงิน ผ่าน REST/JSON · webhook (แบบอะซิงโครนัส)
  5. จาก ตัวเชื่อม open banking ไปยัง ERP หรือบัญชีแยกประเภท: ธุรกรรมที่ปรับเป็นมาตรฐานแล้ว ผ่าน REST/JSON (เส้นทางหลัก)
  6. จาก API ธนาคารหรือผู้รวบรวมข้อมูล ไปยัง ตัวเชื่อม open banking: ความยินยอมหมดอายุหรือถูกถอน ผ่าน HTTP 401 · 403 (เส้นทางข้อยกเว้น)
  7. จาก ตัวเชื่อม open banking ไปยัง แอปหรือแพลตฟอร์มของคุณ: ขอให้ลูกค้าต่ออายุความยินยอม (เส้นทางข้อยกเว้น)

ผลงานในบริการทางการเงิน

กรณีศึกษา

วิธีเริ่มต้น

ขั้นตอนถัดไป

  1. การนัดหมายเวลา

    ทีมของเราส่งอีเมลถึงคุณเพื่อนัดหมายเวลาสำหรับการปรึกษา

  2. การปรึกษาก่อนเริ่มงาน

    การปรึกษาก่อนเริ่มงานออนไลน์ฟรี 30 นาที: เราพูดคุยถึงเป้าหมาย ระบบ และข้อจำกัดของคุณ

  3. การทบทวนความพร้อม

    ในการทบทวนความพร้อมฟรี 48 ชั่วโมง สถาปนิกหลักจะตรวจสอบโครงการของคุณเทียบกับนิยามของความพร้อม 6 ข้อ และแนะนำแนวทางที่เหมาะที่สุด

  4. การเลือกแนวทาง

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

วิธีเริ่มต้นที่เร็วที่สุดคือแพ็กเกจ สปรินต์ความพร้อมด้านการออกใบแจ้งหนี้อิเล็กทรอนิกส์ตามข้อบังคับและ ERP ซึ่งเป็นหนึ่งในแพ็กเกจเริ่มงานแบบรวดเร็วของเรา

จุดเริ่มต้น

คำถามและคำตอบ

XSIS ทำงานด้านฟินเทคอะไรบ้าง

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

ลิงก์ไปยังคำถามนี้

คุณทำงานภายใต้ข้อกำหนดด้านกฎระเบียบและความปลอดภัยของเราได้หรือไม่

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

ลิงก์ไปยังคำถามนี้

เราต้องแทนที่ระบบ core banking หรือไม่

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

ลิงก์ไปยังคำถามนี้

คุณจัดการข้อมูลบัตรอย่างไร

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

ลิงก์ไปยังคำถามนี้

คุณรองรับ ISO 20022 และการชำระเงินทันทีได้หรือไม่

ได้ เราสร้างบริการที่สร้าง ตรวจสอบ และอ่านข้อความ ISO 20022 ทั้งสำหรับการชำระเงินและรายงานขององค์กร เช่น pain.001 และ camt.053 และสำหรับข้อความระหว่างธนาคารที่ใช้ในระบบชำระเงินทันทีและมูลค่าสูง แต่ละโครงการและธนาคารมีกฎของตนเอง เราจึงทำงานจากคู่มือการนำไปใช้และทดสอบในสภาพแวดล้อมทดสอบของพวกเขา

ลิงก์ไปยังคำถามนี้

คุณสร้างการเฝ้าระวังการฉ้อโกงและธุรกรรมได้หรือไม่

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

ลิงก์ไปยังคำถามนี้

อะไรเป็นตัวกำหนดต้นทุนของโครงการฟินเทค

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

ลิงก์ไปยังคำถามนี้

เริ่มต้นด้วยการพูดคุย ไม่ใช่สัญญา

บอกเราว่าคุณต้องการสร้าง เชื่อมต่อ หรือรักษาความปลอดภัยอะไร สถาปนิกจะพิจารณาร่วมกับคุณ แล้วแนะนำว่าควรเริ่มที่ใด

จองการปรึกษาฟรีขอข้อเสนอ