Fintech101: Learn Product Thinking through A Real-World Case Study

Fintech A Real-World Case Study. Quá trình thiết kế, triển khai và thử nghiệm tính năng đánh giá tín dụng trong luồng onboarding của sản phẩm Buy Now Pay Later (BNPL).

Đây là nội dung buổi guest lecture mà mình được mời chia sẻ trong một lớp học quản lý sản phẩm BPM (Breaking into Product Management). Nội dung xoay quanh một case study rất thực chiến mà mình từng làm trong lĩnh vực Fintech (=Finance + Technology), cụ thể là ví trả sau (Buy Now, Pay Later ~ BNPL) cho một sàn thương mại điện tử.

Có nhiều lý do để mình ngồi xuống và viết lại thành bài hoàn chỉnh:

1.Lý do đầu tiên là để lưu trữ. Mình viết lại bài này, một phần là cho người khác, nhưng phần lớn là cho chính mình. Làm product có quá nhiều thứ vụt qua mỗi tuần, nào là backlog, bug, tradeoff, meeting,..mà nếu không ghi lại thì sau vài tháng hay thậm chí vài tuần, vài ngày là sẽ quên sạch. Đây là cách mình giữ lại trải nghiệm, giữ lại những gì đã từng làm. Biết đâu vài năm nữa, lúc ngồi cà phê đọc lại, mình sẽ thấy: “À hồi đó mình cũng làm được kha khá thứ ghê đó chứ!”

2.Lý do thứ hai là… thói quen “làm product”. Cuối buổi thuyết trình, mình có hỏi người nghe một câu rất PM:

“If this presentation were a product, how would you rate it?”

Kết quả khảo sát như sau:

• 10% chấm 7/10

• 15% chấm 8/10

• 50% chấm 9/10

• 25% chấm 10/10

Trước buổi guest lecture, mình có hơi tham vọng đặt kỳ vọng là không có điểm 7. Nhưng nhìn vào thực tế thì.. Điều này nghĩa là vẫn còn người dùng “chưa hiểu rõ” hoặc chưa hài lòng hoàn toàn. Mà nếu sản phẩm chưa tốt thì… iterate lại thôi. Bản viết này là bản cải tiến. Dành cho bạn nào muốn đọc kỹ lại, hoặc hôm đó chưa nghe trọn vẹn.

3.Lý do thứ ba là để chia sẻ cho cộng đồng những người chuyển ngành (như mình ngày xưa) hoặc là những người tò mò về Fintech.
Mình còn nhớ hồi đầu đang chập chững bước chân vào ngành product, mình rất thích những bài viết kiểu case study: làm tính năng gì, gặp vấn đề gì, giải quyết ra sao, học được gì. Vì lý thuyết thì dễ quên, còn chuyện thật việc thật thì đọng lại lâu hơn nhiều. Vậy nên, trong đây là một câu chuyện thật, từ một tính năng thật, với đủ thứ thật: Onboarding flow, eKYC, Credit scoring, API integration, Golive, Pilot test, Edge case handling,.. và những câu hỏi không có câu trả lời đúng tuyệt đối. Let’s dive in.

Lưu ý nhẹ trước khi đọc: 
>> Nếu chia làm sản phẩm thành hai phần lớn là Discovery và Delivery, thì bài viết này sẽ tập trung chủ yếu vào phần Delivery, tức là giai đoạn triển khai tính năng, làm việc với stakeholder như FrontEnd, Back end dev, xử lý edge case... 
>> Ngoài ra, một số chi tiết đã được điều chỉnh hoặc viết lại theo hướng tổng quát để tránh tiết lộ thông tin quá nhạy cảm hoặc vi phạm NDA. Mong bạn thông cảm nếu đôi chỗ nghe hơi “trừu tượng”. Nhưng về bản chất thì flow, cách làm và bài học rút ra đều là thật.

1.Bối cảnh & Bài toán kinh doanh

Giả sử có một cửa hàng số (Digital Store) - kiểu như một sàn thương mại điện tử - muốn triển khai thêm một dịch vụ tài chính cho phép khách hàng mua hàng trước, trả tiền sau bên cạnh hình thức mua hàng thông thường. Để sử dụng dịch vụ này, khách hàng sẽ cần đi qua một quy trình gọi là Onboarding flow, nơi cửa hàng đánh giá sơ bộ về "nhân thân" và khả năng tín dụng (Credit Scoring-mô hình chấm điểm tín dụng gồm nhiều biến) của người đó, trước khi quyết định có cấp quyền sử dụng hay không

Một cửa hàng số có thể nhìn vào hành vi tiêu dùng của người dùng: họ mua gì, bao lâu mua một lần, mua vào dịp nào, mua bao nhiêu lần, mỗi lần mua với hoá đơn bao nhiêu tiền và từ đó xây dựng một mô hình đánh giá tín dụng “cây nhà lá vườn”. Mô hình này sẽ giúp cửa hàng tự chấm điểm người dùng theo mức độ rủi ro (điểm tín dụng nội bộ của Hệ thống quản lý rủi ro nội bộ - Risk Management Systems). Và tất nhiên, điểm tín dụng nội bộ càng cao thì khả năng được duyệt dùng dịch vụ tài chính càng lớn. Quay lại câu chuyện này, để đánh giá rủi ro tín dụng trong quy trình xét duyệt, cửa hàng có thể tạm phân nhóm người dùng hiện có thành 3 nhóm chính:

1. Low-risk users: Thường xuyên mua hàng (>5 lần) → có lịch sử tiêu dùng tốt → được xem là đáng tin cậy.

1. Medium-risk users: Mua hàng ở mức độ trung bình (>3 lần) → có tín hiệu nhưng chưa đủ rõ ràng.

2. High-risk users: Chưa mua hàng hoặc mới chỉ mua 1–2 lần → thiếu dữ liệu lịch sử → được xem là nhóm rủi ro cao.

Việc phân nhóm này không chỉ phục vụ mục đích phân tích, mà còn ảnh hưởng trực tiếp đến quyết định có duyệt cho khách hàng sử dụng dịch vụ tài chính hay không.

→ Vấn đề: Tỉ lệ được duyệt rất thấp ( ví dụ ~50%) trong Onboarding Flow. Nguyên nhân chính là thiếu thông tin về khách hàng, đặc biệt với nhóm Medium-risk users và High-risk users.

2.Onboarding Flow

Tương ứng với với các màn hình, mình visualization (mô hình hoá)

Technical Foundations for PMs: [TechPM#2] System Thinking, Visualization & Diagrams 101

Trước khi đi sâu vào phần giải pháp cải thiện tỉ lệ duyệt thì chúng mình cùng đi lướt qua một vòng toàn cảnh về luồng Onboarding. Đây vẫn là nơi bắt đầu tất cả mọi thứ. Nếu người dùng không đi qua được bước này, họ không thể sử dụng dịch vụ tài chính. Và nếu luồng này không đủ tốt, thì tỉ lệ duyệt sẽ mãi ở mức thấp.

Đây một ví dụ minh hoạ cho một onboarding flow điển hình trong Fintech (hoặc kể cả Banking) từ lúc người dùng bắt đầu đến lúc hoàn tất định danh khách hàng (eKYC). Lưu ý: Thứ tự và công nghệ ở từng bước có thể khác nhau tùy từng công ty/tổ chức tài chính. Nhưng đa phần đều đi qua những bước chính như: xác minh danh tính, xác thực thông tin, bổ sung dữ liệu, xác nhận đồng ý.

pic0: Bất cứ điểm chạm nào để vào được luồng Onboarding.

pic1: Landing Page: Trang giới thiệu tính năng & xác nhận bắt đầu

pic2: Trang hướng dẫn thực hiện xác minh khuôn mặt

pic3: Bật camera để Liveness check. Đưa mặt vào khung để hệ thống chụp và nhận diện

Liveness check: một bước trong quy trình eKYC, công nghệ giúp hệ thống xác định xem người đang thực hiện định danh có thực sự “sống” và có mặt tại thời điểm đó hay không (nó giúp ngăn người dùng dùng ảnh in, video quay lại khuôn mặt, hoặc mặt nạ 3D để đánh lừa hệ thống). Cấm khuôn mặt bị che khuất hoặc nhắm mắt hoặc deepfake.. Liveness check level cao cấp có thể yêu cầu một số hành động như chuyển động mắt, chớp mắt, nghiêng trái, nghiêng phải, gật đầu,…

eKYC (Electronic Know Your Customer): quy trình số hóa (digital) xác minh danh tính khách hàng nhằm phòng chống rửa tiền, tài trợ khủng bố và bất kỳ hành vi gian lận tài chính. Bây giờ, eKYC cho phép người dùng thực hiện toàn bộ quy trình định danh ngay trên điện thoại hoặc máy tính, thay vì cách truyền thống là đến bất kỳ văn phòng offline nào.

pic4: Chụp mặt trước & sau Căn cước công dân (CCCD) / Quét ảnh QR Code (mặt trước nếu CCCD trước 1/7/2024 hoặc mặt sau nếu CCCD sau 1/7/2024) / Chụp đoạn mã MRZ (mặt sau CCCD). Một trong 3 cách trên sẽ khác nhau theo từng tổ chức tài chính. Nhưng mục đích chung là có thể lấy được những thông tin cơ bản của khách hàng trước khi thực hiện đến bước xác thực danh tính phía sau:

Chụp mặt trước & sau CCCD: Khách hàng thực hiện 2 bước. Sau đó hệ thống dùng công nghệ OCR (Optical Character Recognition) tự động đọc và trích xuất thông tin (số định danh, họ tên, ngày sinh, địa chỉ,…) từ 2 hình ảnh mặt trước / sau CCCD đó. Giúp tăng tốc độ xử lý và hạn chế sai sót khi nhập liệu thủ công.

Quét ảnh QR Code (mặt trước nếu CCCD trước 1/7/2024 hoặc mặt sau nếu CCCD sau 1/7/2024) → bạn có thử dùng phần mềm QR Creator: Scan and Make QRCode thử quét QR code trên CCCD của bạn. Nó sẽ ra một dãy text có dạng: Số CCCD|Số CMND|Tên|Ngày sinh|Giới tính|Địa chỉ thường trú|Ngày phát hành CCCD

Chụp đoạn mã MRZ (mặt sau CCCD) → tương tự sau khi quét ta cũng cũng thu đượccác thông tin cơ bản

pic5: Xác thực thông tin sinh trắc học bằng hardware (chạm mặt chip trên CCCD vào thiết bị di động) hoặc bằng software (jump sang ứng dụng VNeID). Cả 2 cách, thông tin sinh trắc học (Biometrics) của khách hàng đều sẽ đi đối chiếu trực tiếp với dữ liệu của Nhà nước / Bộ Công An.

NFC (Near Field Communication) là công nghệ kết nối không dây tầm ngắn, cho phép giao tiếp giữa hai thiết bị đặt gần nhau, thường là dưới 4cm.

VNeID: Hệ thống định danh điện tử của Việt Nam.

Ở bước này, đôi khi hệ thống đã dùng Face Matching: công nghệ so sánh khuôn mặt của người dùng trong video/selfie với ảnh chân dung trên giấy tờ tùy thân. Đây là một bước không thể thiếu trong eKYC, góp phần tăng độ chính xác và giảm rủi ro gian lận danh tính.

pic6: Hiển thị thông tin cá nhân từ chip NFC CCCD để khách hàng xác nhận

pic7: Khách hàng điền thêm thông tin liên hệ (tên người thân, số điện thoại …) trong trường hợp các tổ chức tài chính cần liên hệ (hay nói dân dã hơn là trong trường hợp thu hồi nợ - debt collection)

pic8: Nhập mã OTP để e-Signature (chữ ký điện tử). Hoàn tất quy trình Onboarding

e-Signature (chữ ký điện tử): cho phép khách hàng ký online vào các hợp đồng, cam kết hoặc giấy tờ pháp lý khi mở tài khoản hoặc sử dụng dịch vụ tài chính, mà không cần in ra hay gặp mặt trực tiếp. Có giá trị tương đương với chữ ký tay, nếu được xác thực và lưu trữ đúng chuẩn

OTP có thể gửi qua tin nhắn SMS (SMS OTP) hoặc qua cuộc gọi thoại (Voice OTP)

pic9: Trang hiển thị kết quả xét duyệt quyền sử dụng dịch vụ (Approve, Reject, Pending)

3. Mục tiêu & Chiến lược giải quyết

Quay trở lại về mục tiêu và giải pháp cho bài toán tăng tỉ lệ duyệt dịch vụ tài chính

Ví dụ: Mục tiêu của dự án rất cụ thể: nâng tỷ lệ duyệt dịch vụ tài chính trong luồng onboarding từ 50% lên 70%.

Để đạt được điều đó, chúng mình đặt câu hỏi ngược lại:

• Làm thế nào (How)? → Cần thu thập thêm thông tin về khách hàng.

• Thông tin gì (What)? → Những dữ liệu có thể giúp đánh giá rủi ro tín dụng chính xác hơn.

• Lấy từ đâu (Where)? → Có hai nguồn khả dĩ:

  1. Từ bên thứ ba, ví dụ như tích hợp với các tổ chức chấm điểm tín dụng

  2. Từ chính khách hàng, thông qua việc upload thêm giấy tờ như sao kê lương, chứng minh thu nhập,…

Từ đó, chúng mình đưa ra hai hướng giải pháp chính:

• Option 1: Tích hợp với bên thứ ba để lấy thông tin tín dụng một cách tự động và thuận tiện.

• Option 2: Yêu cầu người dùng cung cấp thêm tài liệu chứng minh năng lực tài chính.

Cả hai hướng đều khả thi, nhưng mỗi bên có trade-off riêng về trải nghiệm người dùng, effort kỹ thuật và độ tin cậy của dữ liệu. Khi cân nhắc giữa hai phương án, thì team mình buộc phải đặt ra câu hỏi: hướng nào khả thi hơn, ít friction hơn cho người dùng?

Phương án yêu cầu người dùng upload giấy tờ (như sao kê lương, hợp đồng lao động…) nghe có vẻ đơn giản, nhưng thực tế lại gây ra nhiều rào cản:

• Người dùng có thể không đủ tin tưởng để chia sẻ thông tin tài chính cá nhân với một cửa hàng số.

• Việc phải đi tìm file, chụp ảnh, upload… cũng tăng nguy cơ bỏ cuộc giữa chừng (drop off luồng) .

Trong khi đó, nếu chọn tích hợp với bên thứ ba:

• Người dùng không cần thao tác thêm, hệ thống sẽ tự động lấy dữ liệu sau khi được họ đồng ý.

• Trải nghiệm người dùng liền mạch hơn, vẫn đảm bảo bảo mật và minh bạch.

→ Sau khi trao đổi và đánh giá cùng team, tụi mình quyết định chọn phương án tích hợp với bên thứ ba là hướng triển khai chính – vừa khả thi, vừa tối ưu trải nghiệm.

4.Một số tổ chức chấm điểm tín dụng

Khi đã quyết định chọn phương án tích hợp bên thứ ba để thu thập thêm thông tin tín dụng, bước tiếp theo là đánh giá xem nên kết nối với đơn vị nào. Vì mỗi tổ chức sẽ có nguồn dữ liệu, cách truy cập và điều kiện pháp lý khác nhau. Dưới đây là một số tổ chức cung cấp dữ liệu tín dụng phổ biến:

1. CIC (Credit Information Center): là Trung tâm Thông tin Tín dụng Quốc gia trực thuộc Ngân hàng Nhà nước. CIC tổng hợp dữ liệu tín dụng của gần như tất cả các ngân hàng và tổ chức tài chính tại Việt Nam. Muốn truy cập dữ liệu CIC, thường phải đi thông qua ngân hàng.

2. PCB (Private Credit Bureau): là công ty cổ phần cung cấp thông tin tín dụng, được liên danh giữa nhiều ngân hàng lớn như Vietcombank, VietinBank,… Dữ liệu từ PCB chủ yếu cũng lấy từ hệ thống của các ngân hàng thành viên, và tương tự như CIC, cần tích hợp gián tiếp thông qua ngân hàng.

3. Trusting Social: Một công ty chuyên cung cấp các giải pháp chấm điểm tín dụng, định danh và hỗ trợ mở rộng khách hàng dựa trên trí tuệ nhân tạo (AI). Tạo ra mô hình đánh giá tín dụng cho nhóm người chưa từng vay vốn trước đây (underbanked or unbanked)

4. DataNest: Cung cấp thông tin tín dụng dựa trên dữ liệu viễn thông

5. KCI (Red Information): Là một tổ chức mới trong lĩnh vực đánh giá tín dụng cá nhân, tập trung vào phân tích dữ liệu thay thế (alternative data).

Sau khi phân tích các lựa chọn, team mình sẽ chọn một trong các bên này để tích hợp vào luồng Onboarding, với mục tiêu bổ sung dữ liệu tín dụng cho những user có rủi ro cao từ đó nâng cao khả năng xét duyệt, mà không làm gián đoạn trải nghiệm người dùng (vì lý do bảo mật nên mình sẽ không thể nói rõ là sẽ tích hợp với tổ chức cụ thể nào)

5. Chi tiết tính năng

5.1 High level design-Logic hoạt động (for all stakeholders)

Sau khi thiết kế lại luồng onboarding và xác định sẽ tích hợp thêm dữ liệu tín dụng từ bên thứ ba, bước tiếp theo là xác định logic hoạt động của hệ thống đánh giá. Kết hợp dữ liệu nội bộ và bên ngoài để ra quyết định duyệt

Cách làm của tụi mình là kết hợp giữa hai nguồn dữ liệu:

1. Dữ liệu hành vi mua sắm (có sẵn): Lịch sử mua hàng, tần suất giao dịch, loại sản phẩm đã mua…→ Từ đó hệ thống tự tính ra một điểm tín dụng nội bộ (internal credit score).

2. Dữ liệu tín dụng bên ngoài → Đây là điểm bổ sung cho các trường hợp mà dữ liệu nội bộ chưa đủ (cảm thấy "chưa đủ tin"), thêm dữ liệu từ bên ngoài để “tăng sáng” cho bức tranh đánh giá rủi ro.Và việc này giúp giảm thiểu từ chối sai (false negative), tránh trường hợp người có khả năng chi trả tốt lại bị từ chối chỉ vì thiếu lịch sử tiêu dùng nội bộ.

Ví dụ: Một khách hàng chỉ mới mua hàng 1–2 lần trên nền tảng (thuộc nhóm high-risk theo dữ liệu nội bộ), nhưng khi truy vấn thông tin từ bên thứ ba, hệ thống phát hiện người này có lịch sử tín dụng tốt tại ngân hàng A, trả nợ đúng hạn, không có nợ xấu.
→ Trong trường hợp này, tổng điểm tín dụng sau khi kết hợp lại đủ để chấp nhận người này vào sử dụng dịch vụ tài chính của Cửa hàng số.

Sau khi xác định sẽ kết hợp dữ liệu tín dụng từ bên thứ ba, câu hỏi tiếp theo là:
Tích hợp ở đâu trong luồng? Và người dùng sẽ trải nghiệm như thế nào?

Ở góc độ high-level, nếu đứng từ trên nhìn toàn bộ luồng Onboarding, bạn sẽ thấy rất nhiều điểm có thể “chen” vào. Nhưng với team mình, sau khi cân nhắc về mặt logic và trải nghiệm người dùng, tụi mình quyết định đặt bước tích hợp bên thứ ba vào giữa hai bước sau:

• Bước khách hàng điền thêm thông tin liên hệ (tên người thân, số điện thoại …)

• Bước khách hàng nhập mã OTP để e-Signature (chữ ký điện tử)

Lý do là vì:

• Đây là thời điểm người dùng đã cung cấp đủ thông tin nội bộ,

• Và Risk Management Systems (Risk engine) với thông tin người dùng đã nhập + lịch sử tiêu dùng sẵn có có thể đánh giá sơ bộ để quyết định có cần lấy thêm dữ liệu từ bên ngoài hay không. Kết quả chia làm 2 nhánh:

  • Người dùng đủ điều kiện (ví dụ đạt điểm A hoặc B) → Không cần làm gì thêm → Đi thẳng tới bước ký xác nhận và hoàn tất luồng.

  • Người dùng chưa đủ điểm (ví dụ điểm C) → Hệ thống quyết định gọi thêm thông tin từ bên thứ ba→ Nhưng trước khi gọi, phải có sự đồng ý từ người dùng.

Để tuân thủ pháp lý và đảm bảo minh bạch, tụi mình chèn thêm một bước hiển thị rõ ràng (tách riêng một màn hình) thông báo cho người dùng biết. Cũng như rất nhiều người dùng không đọc kỹ điều khoản, nên tụi mình thiết kế một màn hình riêng cho bước consent, thay vì nhồi chung vào bước “Điền thêm thông tin liên hệ”. Làm vậy vừa minh bạch, vừa tránh bị khiếu nại về sau.

“Để hoàn tất xét duyệt, chúng tôi cần thêm thông tin tín dụng của bạn từ một đơn vị đối tác đáng tin cậy. Bạn có đồng ý chia sẻ không?”

Người dùng có hai lựa chọn:

• Đồng ý (Yes) → Hệ thống gửi mã OTP để xác nhận việc chia sẻ dữ liệu → Sau khi xác thực xong, sẽ truy vấn điểm tín dụng từ bên thứ ba → Quay lại hệ thống của Cửa hàng số → Ra quyết định cuối cùng.

• Từ chối (No) → Người dùng quay lại flow chính, nhưng rất có thể sẽ bị từ chối dịch vụ do thiếu thông tin để đánh giá.

5.2 FrontEnd / UI (for FE dev / designer)

Sau khi logic đã rõ, (bước xuống một bậc thang) tiếp theo là mapping thành các màn hình UI cụ thể, dành cho các bạn FE dev và designer:

1. Màn hình lấy consent người dùng
   Hiển thị thông báo: “Để hoàn tất xét duyệt, chúng tôi cần xin phép truy vấn điểm tín dụng của bạn từ đối tác. Bạn có đồng ý không?”

2. Nếu đồng ý → chuyển qua bước nhập OTP để xác nhận

3. Sau khi xác thực thành công → hệ thống tự động gọi API, lấy điểm tín dụng từ bên thứ ba

4. Nếu từ chối → bỏ qua, quay lại luồng chính (và khả năng bị từ chối cao)

5.3 BackEnd (for FE dev / BE dev)

Khi đã có luồng logic rõ ràng và thiết kế UI cụ thể, bước tiếp theo là làm sao để frontend giao tiếp được với backend, và hệ thống của mình giao tiếp được với bên thứ ba → Trước khi đi sâu mình xin nói sơ về API (cho những ai chưa biết)

API-Service-Database: Để một hệ thống backend hoạt động mượt mà và có thể giao tiếp được với frontend hay các hệ thống bên ngoài, cần hiểu ba thành phần chính sau:

• API là cầu nối trung gian giữa các phần mềm, hệ thống hoặc thiết bị, cho phép chúng giao tiếp với nhau một cách. Nói nôm na, API giống như “menu trong nhà hàng” – bạn không cần vào bếp, chỉ cần gọi đúng món → bếp (backend) sẽ nấu → mang ra cho bạn.

• Service là nơi chứa các đoạn logic xử lý chính trong backend. Mỗi API khi được gọi sẽ đi qua các service này để tính toán, kiểm tra, xử lý dữ liệu,.. trước khi trả về kết quả. Với những hệ thống lớn, các service thường được tách nhỏ thành microservice-là các module độc lập, có thể chạy riêng, deploy riêng, scale riêng.

• Cuối cùng, dữ liệu cần được lưu lại ở đâu đó → Database. Service sẽ truy vấn database để: Lấy dữ liệu (read), Cập nhật / thêm mới (write), Xoá hoặc xử lý dữ liệu (delete, archive,…)

Client side - Server side. Góc nhìn hệ thống đơn giản:

• Client (ứng dụng trên điện thoại, laptop, browser…) sẽ gửi yêu cầu (request),

• Server sẽ xử lý và trả về kết quả (response).

→ Hoặc sau bài Fintech101, bạn có thể đọc thêm về bài viết APIs101 của mình tại đây:

Technical Foundations for PMs: [TechPM#1] API Basics

Luồng của mình sẽ cần nhiều API, chia làm 2 nhóm:

1. API nội bộ (của Digital Store) kết nối giữa frontend và backend hệ thống của chính mình. Ví dụ: gọi API để gửi OTP, xác nhận số điện thoại, hiển thị kết quả xét duyệt...

2. API tích hợp bên thứ ba: nơi backend của mình gọi tới hệ thống của đối tác (ví dụ CIC, Trusting Social, ngân hàng..)

Khi luồng logic đã rõ và API đã được xác định, bước tiếp theo là diễn tả chi tiết các bước giao tiếp giữa hệ thống của mình và đối tác thứ ba. Đây là lúc mình cần đến mô hình hoá Sequence Diagram. Sequence diagram là một loại sơ đồ mô tả chuỗi tương tác giữa các hệ thống (hoặc thành phần trong hệ thống) theo trật tự thời gian. Đây là công cụ cực kỳ hữu ích, đặc biệt trong những domain có nhiều hệ thống giao tiếp phức tạp như Fintech.

Trong thực tế, mỗi lần bạn làm việc với backend dev, hoặc phải explain cho một tech stakeholder, bạn sẽ rất dễ “lost in translation” nếu chỉ nói miệng hoặc viết bằng word. Sequence Diagram giúp:

• Biết ai gọi ai, ai gửi ai nhận, API này trigger khi nào

• Phản hồi về ra sao?

• Cần chờ, xác nhận, hay xử lý gì?

• Dễ visualize các bước và xử lý các edge case sau này

Sơ đồ vẽ đúng còn có thể tiết kiệm hàng giờ thảo luận và hàng tuần debugging.

Tùy vào công ty, ai phụ trách vẽ những sơ đồ này:

• BA (Business Analyst): nếu có team rõ ràng và tách biệt vai trò.

• PM/Product: nếu làm ở công ty thiên lean/agile hoặc team nhỏ

• Với team mình thì: Mình, với vai trò là Product phụ trách luôn phần này, từ high-level flow đến sequence diagram kỹ thuật.

Luồng cụ thể. Giả sử người dùng đã bấm “Đồng ý chia sẻ dữ liệu”, thì backend của hệ thống của Digital Store sẽ thực hiện luồng API step-by-step như sau:

1. API Authentication→ Gửi yêu cầu lấy token truy cập tới hệ thống bên thứ ba → Nhận về access token

2. API Send OTP → Dùng token vừa lấy được để gọi API gửi OTP → Bên thứ ba gửi tin nhắn OTP đến điện thoại người dùng

3. API Verify OTP → Người dùng nhập mã OTP → Backend gọi API verify để xác nhận mã chính xác → Nếu thành công → bước tiếp theo

4. API Get Credit Info → Sau khi OTP được xác thực, hệ thống của mình gọi API để lấy dữ liệu tín dụng từ bên thứ ba → Kết quả sẽ được backend xử lý và đưa ra quyết định duyệt hay không

5.4 BackEnd - Integrate (for BE dev)

Sau khi đã có:

• Bức tranh tổng thể (onboarding flow + integration point)

• Sequence Diagram (thể hiện từng bước giao tiếp)

• Các API dự kiến sẽ gọi

→ Bước tiếp theo là đào sâu hơn vào phần tích hợp thực tế giữa hệ thống của mình và hệ thống bên thứ ba.

Ở phần này, mình sẽ:

• Làm rõ từng API request: gửi gì, nhận gì, định dạng ra sao

• Định nghĩa timeout, retry, error-handling logic

• Document chi tiết các field, validation, mã hóa, chữ ký số nếu có

• Đảm bảo các ràng buộc bảo mật, đặc biệt với dữ liệu người dùng

Đây là phần mà giao tiếp giữa PM/BA với backend dev cần càng rõ ràng càng tốt, vì nếu mơ hồ bước nào là rất dễ sai bước đó.

Mình thường highlight một số phần quan trọng như sau để tránh dev dễ làm sai, tốn thời gian test & debug, chậm tích hợp:

Documentation kỹ thuật: Càng rõ càng tốt

1. API Endpoint
+ Ghi rõ URL của API (có thể là bản staging và production).
+ Phải phân biệt non-live (môi trường test) và live (môi trường thật) để tránh việc test sai môi trường gây sự cố sản phẩm.

2. API Description
+ Mô tả chức năng của từng API.Ví dụ: POST /send-otp dùng để yêu cầu đối tác gửi mã OTP đến số điện thoại người dùng.

3. HTTP Method. Ghi rõ phương thức: POST, GET, PUT, DELETE
Hầu hết các API tương tác với bên thứ ba (gửi OTP, xác thực, lấy thông tin...) đều là POST.

4. Request / Response Structure
+ Phần này rất quan trọng, đặc biệt khi có validate format hoặc yêu cầu mã hóa. 

+ Ví dụ với field phone_number:
> Format bắt buộc: Phải đủ 10 chữ số, bắt đầu bằng 84 (thay vì 0)
> Yêu cầu: Nếu phía frontend trả về 0901234567, backend phải convert thành 84901234567 trước khi gửi qua partner.

+ Dữ liệu cần được encode/mã hóa theo định dạng nào (nếu có)

5. Encryption & Signature
+ Encryption: Trường nào cần mã hóa? Dùng phương pháp gì? (RSA, AES, base64…)

+ Signature: Có yêu cầu ký request không? Nếu có:
> Chuỗi để ký gồm những phần nào?
> Cách tạo hash/signature?
> Đây là lớp bảo vệ quan trọng đảm bảo dữ liệu người dùng không bị giả mạo hoặc đánh cắp khi gửi qua bên thứ ba.

5.5 BackEnd - Error Code Handling (for BE dev)

→ Happy Case thì dễ, Edge case mới là bài “kiểm tra” thật

Vì khi hệ thống chạy “happy case”. Mọi thứ đều đúng, server trả về httpStatus 200 OK, dữ liệu hợp lệ, thì quá trình gần như “trơn tru và dễ chịu”. Nhưng khi mọi thứ không như kỳ vọng, mạng chập chờn, dữ liệu sai định dạng, OTP nhập sai, timeout, app crash, user thoát giữa chừng.. thì mới thấy được hệ thống thật sự có ổn hay không. Xử lý lỗi (error code handling) luôn là phần "nặng đô", phải chuẩn bị trước từng API của đối tác trả mã lỗi thế này thì hệ thống mình xử lý như thế nào. Team mình thường làm bảng tổng hợp theo từng API (như hình).

Ví dụ team mình cũng cần set các SLA cụ thể cho từng API. Nếu tổng thời gian cho cả flow chỉ khoảng 5–6s (theo SLA định sẵn), thì ví dụ Auth Token mất 4s → toàn bộ flow phải skip luôn, không được tiếp tục gọi API khác nữa. Tránh làm người dùng chờ đợi không lý do.

Không chỉ các lỗi từ hệ thống, mà còn những tình huống từ người dùng ("khó đỡ" nhưng cũng cần cover)

• Đang nhập OTP thì điện thoại hết pin

• App bị force quit hoặc crash giữa chừng

• Người dùng thoát app rồi quay lại

Với những case này, mình phải xác định:

• Trạng thái luồng có được lưu lại không?

• Khi quay lại, người dùng bắt đầu từ đâu? Có cần consent lại không? Có phải gửi lại OTP không?

Một PM giỏi không chỉ viết flow đẹp, mà còn phải lường trước điều xấu (edge case) có thể xảy ra ở thời điểm ban đầu (giúp cho Dev & QA hạn chế tốn kém thời gian fix lỗi về sau)

5.6 Golive / Pilot / Greyscale (for Business, Risk, BE dev)

Sau khi hoàn tất thiết kế, dev, test và review tất cả flow từ UI đến API, từ logic đến error handling tính năng đã sẵn sàng được đưa ra thực tế. Nhưng triển khai ngay 100% cho toàn bộ người dùng thì quá mạo hiểm.

Thay vào đó, mình tiến hành theo đúng tinh thần "test-and-learn"→ Go live theo mô hình pilot, chạy thử với một nhóm nhỏ người dùng. Để kiểm chứng tính năng tích hợp bên thứ ba giúp cải thiện tỷ lệ duyệt, mình chia user làm 2 nhóm:

• Treatment group → Nhóm user đi qua luồng mới, có tích hợp gọi thông tin tín dụng từ bên thứ ba.

• Control group → Nhóm user vẫn đi qua luồng cũ, không có thay đổi gì.

Cả hai nhóm đều thuộc cùng một phân khúc, ví dụ như nhóm high-risk users tức là những người vốn dĩ hay bị từ chối do thiếu thông tin → Mục tiêu: So sánh trực tiếp hiệu quả giữa luồng cũ và luồng mới, xem luồng mới có cải thiện tỷ lệ duyệt hay không.

Sau một thời gian chạy pilot, mình sẽ tổng hợp số liệu để đánh giá:

• Nếu kết quả tốt → Tỷ lệ duyệt tăng như kỳ vọng, không phát sinh lỗi, trải nghiệm user ổn → Triển khai 100% toàn bộ user.

• Nếu kết quả không như mong đợi → Ví dụ: user có điểm tín dụng tốt nhưng vẫn bị reject, hoặc flow quá chậm khiến user bỏ giữa chừng → Dừng rollout, bắt đầu deep-dive phân tích nguyên nhân, có thể cần:

  • Điều chỉnh logic risk engine

  • Thay đổi ngưỡng điểm xét duyệt

  • Hoặc tệ nhất: quay lại luồng cũ (rollback) → uổng phí nguồn lực (tiền bạc + con người)

6. Một vài bài học của riêng mình

• Discovery hay là một chuyện, nhưng Delivery cũng là nơi "chết người" nếu bạn không đủ sâu sát. Delivery tốt → Discovery dễ hơn. Biết hệ thống giới hạn đến đâu, đánh giá tính khả thi của chiến lược ngay từ đầu.

• Hiểu tech không giúp bạn code nhưng giúp bạn giải quyết vấn đề và nói cùng ngôn ngữ với dev dễ build được trust → làm việc hiệu quả và dễ hơn.

• Làm Product, đặc biệt là trong Fintech, không hề dễ. Không có "best practice" duy nhất cho mọi tình huống.

Lời kết

Nếu bạn đã đọc đến đây, cảm ơn vì đã đồng hành cùng một bài viết có thể xem như "step-by-step" trong việc xây dựng một tính năng thực tế trong Fintech. Hy vọng case study nhỏ này giúp bạn hình dung rõ hơn về bức tranh thực tế phía sau một dòng thông báo tưởng như đơn giản: “Dịch vụ tài chính của bạn đã được phê duyệt.”

And again again. Một câu hỏi rất PM như thường lệ.

“If this article were a product, how would you rate it? In the scale 1 to 10 (if 1 is the worst and 10 is the best)”

Bạn hãy để lại comment hoặc anything cho mình biết nhé👇. Peace !

Còn bạn muốn coi video, thì link ở đây nhen: