NGÀNH CNTT TUYỂN SINH NHIỀU CHỈ TIÊU NGÀNH CNTT, CNTT VIỆT NHẬT VÀ KHOA HỌC DỮ LIỆU

Chapter 0: Vì sao Data Analyst trong lĩnh vực Fintech cần hiểu tài chính?

on .

Chapter 0: Vì sao Data Analyst trong lĩnh vực Fintech cần hiểu tài chính?

Giới thiệu Series Data Analyst trong lĩnh vực Fintech

Trong thời đại ngân hàng số, ví điện tử và ứng dụng đầu tư mọc lên như nấm, Data Analyst (DA) trở thành một mắt xích quan trọng để biến dữ liệu thành giá trị kinh doanh. Series Data Analyst trong lĩnh vực Fintech được viết ra nhằm cung cấp kiến thức cơ bản đặc biệt dành cho những bạn DA muốn trang bị kiến thức nền tảng để tự tin bước vào lĩnh vực fintech. Nội dung chuỗi bài viết này chủ yếu sẽ được dựa vào cuốn sách “Tiền và hoạt động ngân hàng”, “Fintech for dummies” và tổng hợp từ nhiều nguồn khác nhau. Nội dung các chap sẽ bao gồm:

Chapter 0: Vì sao Data Analyst trong lĩnh vực Fintech cần hiểu tài chính?

Chapter 1: Tiền và ngân hàng

Chapter 2: Hoạt động và số hóa ngân hàng

Chapter 3: Các sản phẩm tài chính

Chapter 4: Chỉ số tài chính

Chapter 5: Dữ liệu và bài toán minh họa

Chapter 6: Chủ đề nâng cao

Tại Chapter 0, chúng ta sẽ cùng tìm hiểu vai trò của DA trong lĩnh vực fintech cùng một ví dụ tình huống cần nắm chắc kiến thức ngành (domain knowledge) để tiến hành phân tích và đề xuất giải pháp.

Trong một công ty fintech, Data Analyst không chỉ “ngồi với số liệu” mà còn đóng vai trò cầu nối giữa dữ liệu và chiến lược kinh doanh. Công việc của bạn có thể bao gồm:

  • Theo dõi hiệu suất sản phẩm, chẳng hạn đo lường tỷ lệ người dùng kích hoạt ví điện tử sau khi tải ứng dụng.

  • Phân tích hành vi người dùng dựa trên lịch sử giao dịch, hoạt động nạp/rút tiền, thanh toán.

  • Đo lường rủi ro, như tỷ lệ nợ xấu hoặc trả chậm.

  • Hỗ trợ các quyết định chiến lược, ví dụ đánh giá hiệu quả chiến dịch marketing.

Vì sao cần hiểu kiến thức ngành (domain knowledge)? Cùng tới với hai ví dụ sau:

Ví dụ 1: Hãy tưởng tượng bạn là một Data Analyst cho một công ty Fintech cung cấp ví điện tử. Ban lãnh đạo yêu cầu bạn làm một báo cáo khẩn cấp về Tổng Giá Trị Giao Dịch (Total Transaction Value - TTV) trong ngày siêu sale 8/8 vừa qua để đánh giá hiệu quả của chiến dịch marketing.

Trong cơ sở dữ liệu, bạn có một bảng transactions với các cột quan trọng như transaction_id, amount (số tiền), transaction_date (ngày giao dịch), và status (trạng thái).

Cột status có thể có các giá trị như:

  • pending: Giao dịch đã được khởi tạo nhưng đang chờ xử lý, tiền chưa thực sự được chuyển đi (ví dụ: chờ ngân hàng đối tác xác nhận).

  • settled hoặc success: Giao dịch đã hoàn tất, tiền đã được chuyển thành công.

  • failed: Giao dịch thất bại do lỗi kỹ thuật, sai thông tin, hoặc tài khoản không đủ tiền.

 

Data Analyst A - chỉ tập trung vào kỹ thuật

Data Analyst B - có kiến thức ngành

Cách tiếp cận

Chỉ nhận yêu cầu rồi viết câu lệnh SQL để tính tổng giá trị giao dịch trong ngày

Hiểu rằng: "Tổng giá trị giao dịch" thực tế mà doanh nghiệp ghi nhận phải là những giao dịch đã thành công (settled). Các giao dịch pending có rủi ro thất bại và không thể được tính là doanh thu hay giá trị đã tạo ra

Câu lệnh SQL

SELECT SUM(amount) AS total_value

FROM transactions

WHERE transaction_date = '2025-8-8';

SELECT SUM(amount) AS total_value

FROM transactions

WHERE transaction_date = '2025-8-8' 

AND status = 'settled';

Kết quả

15 tỷ đồng (bao gồm cả settled, pending, failed)

12 tỷ đồng (chỉ tính settled)

Sự chênh lệch 3 tỷ đồng giữa hai kết quả trên không chỉ là một con số, nó dẫn đến những quyết định kinh doanh sai lầm nghiêm trọng:

  • Đánh giá sai hiệu quả Marketing:

    • Với báo cáo 15 tỷ, ban lãnh đạo nghĩ rằng chiến dịch marketing đã thành công vượt bậc. Họ quyết định đổ thêm gấp đôi tiền marketing cho chiến dịch tháng sau với kỳ vọng thu về 30 tỷ.

    • Thực tế, chiến dịch chỉ mang về 12 tỷ. Quyết định đổ thêm tiền dựa trên con số sai lầm sẽ gây lãng phí ngân sách trầm trọng.

  • Sai lệch trong báo cáo tài chính: Bộ phận Kế toán/Tài chính khi đối soát dòng tiền cuối tháng sẽ thấy hụt 3 tỷ so với báo cáo của team Data. Điều này gây ra sự hoang mang, mất thời gian điều tra, và quan trọng nhất là làm giảm sút niềm tin vào năng lực của đội ngũ phân tích dữ liệu.

  • Hoạch định sai chiến lược sản phẩm: Công ty có thể nghĩ rằng hệ thống đang hoạt động tốt vì xử lý được tới 15 tỷ giao dịch, trong khi thực tế có tới 3 tỷ (tương đương 20%) đang bị "treo" ở trạng thái pending hoặc failed, cho thấy một vấn đề tiềm ẩn về kỹ thuật hoặc trải nghiệm người dùng cần được giải quyết.

Ví dụ 2: Bạn là một Data Analyst làm việc cho một cổng thanh toán (Payment Gateway) cung cấp dịch vụ cho hàng ngàn website thương mại điện tử. Đột nhiên, Trưởng phòng Rủi ro nhận thấy số lượng các yêu cầu chargeback (khách hàng khiếu nại ngân hàng để đòi lại tiền) tăng vọt trong tuần qua. Lý do khiếu nại phổ biến là: "Tôi không thực hiện giao dịch này".

Mỗi yêu cầu chargeback thành công không chỉ khiến công ty mất tiền mà còn bị các tổ chức thẻ quốc tế (Visa, Mastercard) phạt và làm giảm uy tín. Bạn được giao nhiệm vụ khẩn cấp: "Tìm ra chuyện gì đang xảy ra."

Bảng chargeback bao gồm các cột:

  • chargeback_id: Mã định danh duy nhất cho mỗi yêu cầu chargeback (khóa chính).

  • transaction_id: Cột quan trọng nhất. Đây là khóa ngoại dùng để liên kết (JOIN) tới giao dịch gốc trong bảng transactions. Nhờ cột này, nhà phân tích có thể truy vết lại toàn bộ thông tin về người dùng, nhà bán hàng, thiết bị,... liên quan đến giao dịch bị khiếu nại.

  • chargeback_date: Ngày mà yêu cầu chargeback được ghi nhận.

  • reason_code: Mã lý do khiếu nại do ngân hàng cung cấp. Mỗi mã tương ứng với một lý do cụ thể. Ví dụ:

    • 10.4: Fraud - Card-Not-Present Transaction (Gian lận - Giao dịch không xuất trình thẻ)

    • 13.1: Goods/Services Not Received (Không nhận được hàng hóa/dịch vụ)

  • status: Trạng thái của khiếu nại (ví dụ: pending_investigation, won, lost).

  • amount: Số tiền bị khiếu nại, thường bằng với số tiền của giao dịch gốc.

 

Data Analyst A - chỉ tập trung vào kỹ thuật

Data Analyst B - có kiến thức ngành

Cách tiếp cận

Tiếp cận vấn đề một cách trực diện. Họ viết một câu lệnh SQL để nhóm các khiếu nại theo nhà bán hàng (merchant)

Để tìm ra gian lận, không thể chỉ nhìn vào bảng chargebacks, mà phải kết nối dữ liệu từ nhiều nguồn khác nhau. Họ bắt đầu thực hiện các truy vấn phức tạp hơn để tìm các mẫu hành vi bất thường liên quan đến các giao dịch của "Merchant ABC"

Câu lệnh SQL

SELECT merchant_id, COUNT(chargeback_id) AS total_chargebacks

FROM chargebacks

WHERE chargeback_date >= '2025-08-08'

GROUP BY merchant_id

ORDER BY total_chargebacks DESC;

JOIN transactions với device_logs (ghi nhận thông tin thiết bị):
Phát hiện hàng trăm giao dịch khác nhau, dùng hàng trăm số thẻ tín dụng, nhưng đều thực hiện từ cùng một thiết bị (device_id).
→ Kiến thức ngành: Đây là dấu hiệu kinh điển của card testing - kẻ gian dùng phần mềm tự động thử nhiều thẻ tín dụng bị đánh cắp để tìm thẻ còn hoạt động.

JOIN transactions với user_accounts (tài khoản người dùng) và shipping_details (địa chỉ giao hàng):
Phát hiện hàng trăm tài khoản mới được tạo trong thời gian ngắn, tất cả đều yêu cầu giao hàng đến cùng một địa chỉ.
→ Kiến thức ngành: Đây là dấu hiệu một ổ nhóm gian lận đang gom hàng hóa mua từ thẻ bị đánh cắp.

Kết quả

Báo cáo chỉ ra rằng 80% các khiếu nại trong tuần qua đều đến từ một nhà bán hàng duy nhất là "Merchant ABC".

Hiểu rằng chỉ nhìn vào bảng chargebacks là chưa đủ, cần kết nối dữ liệu từ nhiều nguồn khác nhau.
Hậu quả của cách tiếp cận 1:

  • Công ty có thể cắt đứt hợp đồng với "Merchant ABC" một cách oan uổng, vừa mất đi một đối tác kinh doanh hợp pháp, vừa mất doanh thu.

  • Quan trọng nhất: Vấn đề gốc không được giải quyết. Băng nhóm lừa đảo kia sẽ đơn giản chuyển sang tấn công một merchant khác, và khủng hoảng chargeback sẽ lại tiếp diễn.

Giải pháp từ cách tiếp cận 2:

  • Hành động ngay lập tức: Dựa trên các mẫu hành vi được phát hiện, team Rủi ro có thể ngay lập tức thiết lập các quy tắc (rules) mới trên hệ thống để tự động chặn các giao dịch đáng ngờ. Ví dụ: "Tự động khóa một thiết bị nếu nó cố gắng giao dịch với hơn 5 thẻ khác nhau trong vòng 1 giờ."

  • Giải pháp dài hạn: Các phân tích và "dấu vết" này cung cấp dữ liệu vàng để huấn luyện các mô hình Machine Learning, giúp hệ thống tự động nhận diện các hành vi gian lận tinh vi hơn trong tương lai.

Hai ví dụ trên cho thấy, một Data Analyst giỏi trong ngành Fintech không chỉ cần biết cách lấy dữ liệu, mà phải hiểu sâu sắc ý nghĩa đằng sau mỗi trường dữ liệu để biến chúng thành những insight chính xác và có giá trị chiến lược. Phân tích sâu sắc như vậy không chỉ giải quyết vấn đề trước mắt mà còn giúp xây dựng một nền tảng tài chính an toàn và bền vững hơn.

 

Hy vọng phần mở đầu này đã giúp bạn hình dung rõ hơn vai trò của Data Analyst trong fintech, cũng như lý do vì sao kiến thức ngành là “vũ khí” không thể thiếu. Bước sang Chapter 1, chúng ta sẽ bắt đầu từ những viên gạch nền tảng nhất của thế giới tài chính: tiền và ngân hàng — hai khái niệm tưởng quen thuộc nhưng chứa đựng nhiều điều bất ngờ.

Phạm Hồng Trà