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

Góc học tập

Hacker tấn công Trung tâm Thông tin tín dụng quốc gia

on .

Trung tâm Ứng cứu khẩn cấp không gian mạng Việt Nam (VNCERT) cùng Cục An ninh mạng và phòng, chống tội phạm sử dụng công nghệ cao (A05, Bộ Công an) vừa phát đi thông cáo báo chí xác nhận vụ việc lộ dữ liệu cá nhân tại Trung tâm Thông tin tín dụng quốc gia (CIC).

Cụ thể, ngày 10/9, VNCERT tiếp nhận báo cáo sự cố an ninh mạng tại CIC. A05 đã chỉ đạo VNCERT chủ trì, phối hợp với các doanh nghiệp an toàn thông tin (Viettel, VNPT, NCS), Ngân hàng Nhà nước và CIC để xác minh, đồng thời triển khai các biện pháp kỹ thuật ứng phó.

  Toàn văn thông cáo báo chí của VNCERT.

Toàn văn thông cáo báo chí của VNCERT. 

Kết quả xác minh ban đầu cho thấy có dấu hiệu tội phạm mạng tấn công, xâm nhập nhằm đánh cắp dữ liệu cá nhân. Số lượng dữ liệu bị chiếm đoạt đang tiếp tục được thống kê, làm rõ.

VNCERT yêu cầu các tổ chức, cá nhân không tự ý tải, chia sẻ hay sử dụng trái phép dữ liệu, nếu vi phạm sẽ bị xử lý theo quy định pháp luật. Đồng thời, cơ quan này khuyến nghị các tổ chức tài chính, ngân hàng tăng cường rà soát hệ thống, tuân thủ tiêu chuẩn TCVN 14423:2025 về an ninh mạng.

Người dân cũng được cảnh báo nâng cao cảnh giác, tránh bị lợi dụng thông tin để phát tán mã độc, lừa đảo hoặc chiếm đoạt tài sản.

Nguồn: BÁO MỚI

Cho 3 ví dụ đơn giản phân biệt cách học của con người và AI

on .

Đây là 3 ví dụ dễ hiểu, để thấy sự khác biệt giữa cách học của con người và AI:
 
1. Học ngôn ngữ
  •  Con người: Một em bé nghe bố mẹ nói chuyện hằng ngày, bắt chước dần dần, dù có khi ngữ pháp chưa đúng. Bé hiểu cả ngữ cảnh, cảm xúc, giọng điệu.
  • AI: Cần một lượng dữ liệu văn bản cực lớn (hàng triệu câu), được huấn luyện theo xác suất để đoán từ tiếp theo, không “cảm” được giọng điệu như con người mà chỉ xử lý theo mẫu.
 
2. Nhận diện khuôn mặt
  • Con người: Chỉ cần gặp một người bạn 1–2 lần là có thể nhớ mặt, thậm chí nhận ra dù họ đổi kiểu tóc hay mặc đồ khác.
  • AI: Cần hàng nghìn bức ảnh gắn nhãn để huấn luyện. Nếu hình quá khác so với dữ liệu học (ánh sáng, góc chụp lạ), AI có thể nhầm lẫn.
 
3. Học đi xe đạp
  • Con người: Trẻ nhỏ tập đi xe, ngã vài lần, cơ thể tự điều chỉnh thăng bằng, nhớ lâu nhờ “trí nhớ vận động”.
  • AI (robot): Muốn học đi xe phải lập trình hoặc dùng thuật toán học tăng cường, thử hàng ngàn lần trong mô phỏng rồi mới điều khiển được.
 
Điểm chung: cả con người và AI đều “học” từ dữ liệu/kinh nghiệm. 
Khác biệt: con người học ít ví dụ, hiểu bối cảnh – còn AI thường cần rất nhiều dữ liệu, học theo thống kê và khó linh hoạt bằng.
 
 
 
 

Lãnh vực nào sẽ bị AI cạnh tranh trong tương lai gần?

on .

Nếu nói đến tương lai gần (5–10 năm), những lĩnh vực dễ bị AI cạnh tranh nhất thường có các đặc điểm sau: công việc mang tính lặp lại, quy tắc rõ ràng, xử lý dữ liệu số hóa tốt.

 

1. Lĩnh vực dễ bị cạnh tranh mạnh

  • Văn phòng & hành chính: nhập liệu, xử lý hồ sơ, phân loại email, lập báo cáo.
  • Dịch vụ khách hàng: chatbot, tổng đài tự động, hỗ trợ kỹ thuật cơ bản.
  • Dịch thuật và biên tập sơ cấp: dịch nhanh văn bản, kiểm tra chính tả, viết nội dung chuẩn SEO.
  • Phân tích dữ liệu cơ bản: thống kê, tạo báo cáo từ dữ liệu lớn.
  • Kế toán & tài chính thường nhật: kiểm tra giao dịch, lập hóa đơn, đối soát.
  • Thiết kế cơ bản: poster, logo đơn giản, template web (AI như Canva, Figma AI đang làm rất nhanh).
  • Bán hàng trực tuyến: chăm sóc khách hàng tự động, gợi ý sản phẩm, tối ưu quảng cáo.

2. Lĩnh vực chịu cạnh tranh nhưng AI chỉ hỗ trợ

  • Y tế: AI đọc phim X-quang, MRI, phân tích xét nghiệm nhanh → hỗ trợ bác sĩ nhưng chưa thay thế hẳn.
  • Luật: AI tra cứu án lệ, soạn thảo hợp đồng chuẩn mẫu → luật sư vẫn quyết định cuối cùng.
  • Giáo dục: AI dạy kèm cá nhân, giải bài tập, tạo đề thi → giáo viên vẫn quan trọng cho đào tạo tư duy, đạo đức.
  • Nghệ thuật sáng tạo: AI có thể làm nhạc, tranh, video nhưng vẫn thiếu “cái hồn” nhân sinh mà con người mang lại.

3. Lĩnh vực ít bị AI thay thế

  • Công việc đòi hỏi cảm xúc, sự đồng cảm, và trách nhiệm xã hội: chăm sóc người già, tâm lý trị liệu, lãnh đạo, ngoại giao.
  • Công việc cần tính thủ công, khéo tay, hiện diện vật lý: thợ điện, thợ xây, đầu bếp, y tá chăm sóc trực tiếp.
  • Công việc sáng tạo mang dấu ấn cá nhân đặc biệt: nghiên cứu khoa học, nghệ sĩ độc bản, triết học.

Tóm lại: AI sẽ cạnh tranh mạnh trong công việc mang tính kỹ thuật – lặp lại, còn những ngành nghề cần trí tuệ cảm xúc, óc sáng tạo độc bản, trách nhiệm pháp lý/đạo đức thì AI khó thay thế.

Tư duy logic: Ai tạo ra đấng sáng tạo?

on .

Câu hỏi “Ai tạo ra Đấng Sáng Tạo?” nghe có vẻ hợp lý, nhưng nếu phân tích kỹ thì câu hỏi bị lỗi logic ở chỗ giả định ngầm sai.

Cụ thể, chúng ta xem xét định nghĩa 

Định nghĩa “Đấng Sáng Tạo”

    • Trong hầu hết các hệ thống triết học hoặc thần học, Đấng Sáng Tạo được định nghĩa là nguyên nhân đầu tiênhoặc thực thể tự hữu – tức là không được tạo ra, không phụ thuộc vào bất cứ nguyên nhân nào khác.
    • Khi hỏi “Ai tạo ra Đấng Sáng Tạo?”, chúng ta đã mâu thuẫn với định nghĩa trên, vì câu hỏi ngầm giả định rằng Đấng Sáng Tạo cũng cần một nguyên nhân

Lỗi logic

    • Câu hỏi “Đấng Sáng Tạo ai tạo ra” đưa vào cùng loại với các vật thể trong vũ trụ (vốn cần nguyên nhân), trong khi theo định nghĩa, Đấng Sáng Tạo nằm ngoài chuỗi nguyên nhân.
    • Giống như hỏi: “Màu xanh dài bao nhiêu mét?” – vấn đề lỗi logic ở chỗ thuộc tính “dài” không áp dụng được cho “màu sắc”.

Lỗi tuần hoàn vô hạn 

    • Nếu cứ hỏi “ai tạo ra thực thể A?” cho mọi A, thì sẽ dẫn đến chuỗi nguyên nhân vô tận và không bao giờ giải thích được sự tồn tại của bất cứ thực thể A nào.
    • Khái niệm Đấng Sáng Tạo ra đời vượt qua chuỗi vô tận này.

Tóm lại, câu hỏi này bị lỗi logic, vì giả định sai tiền đề, một thực thể vốn được định nghĩa là “không cần được tạo ra”, lại cần có nguyên nhân tạo ra một thực thể.

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à