Phân hệ PM Study
  • Tình huốngTình huống thực chiến
  • Kịch bảnRa quyết định tình huống
  • Biểu mẫuKho biểu mẫu tải về
  • Thẻ ghi nhớHọc thuật ngữ PMP
  • Công cụMáy tính EVM, PERT, dự phòng
  • Hỏi đápHỏi đáp & thảo luận
  • Thử tháchMỗi ngày một câu hỏi PMP
  • Lý thuyếtBài học PMBOK 8 & ECO 2026
  • Luyện thiThi thử & ôn tập PMP
  • Bài viếtThư viện bài viết PMP
PM Study
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đáp
6 chuyên mụcXem tất cả bài viết →
  • Quản lý các bên liên quanTình huống về kỳ vọng, giao tiếp và gắn kết stakeholder.
  • Lãnh đạo & đội nhómXây dựng, dẫn dắt và giải quyết xung đột trong đội dự án.
  • Kế hoạch & tiến độLập kế hoạch, ước lượng, nén tiến độ và kiểm soát baseline.
  • Rủi ro & thay đổiNhận diện, ứng phó rủi ro và kiểm soát thay đổi phạm vi.
  • Agile & HybridLựa chọn và vận hành cách tiếp cận Agile, Predictive, Hybrid.
  • Luyện thi PMPChiến lược ôn tập và mẹo xử lý câu hỏi tình huống PMP.
Công cụBài viết
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đápChuyên mụcCông cụBài viết
/
PM Study

Học quản lý dự án và ôn thi PMP bằng tiếng Việt: lý thuyết PMBOK® Guide 8, tình huống thực tế và đề luyện thi theo ECO 2026.

Chuyên mục

  • Quản lý các bên liên quan
  • Lãnh đạo & đội nhóm
  • Kế hoạch & tiến độ
  • Rủi ro & thay đổi
  • Agile & Hybrid
  • Luyện thi PMP

Tài nguyên

  • Project Management Institute (PMI)
  • PMP Exam Content Outline
  • The Scrum Guide
  • PMI Vietnam Chapter

PM Study

  • Tất cả bài viết
  • Bài viết nổi bật
© 2026 PM StudyPMP® và PMBOK® là nhãn hiệu đã đăng ký của Project Management Institute.109 người đã truy cậpPhiên bản 1.15.0
  1. /Tình huống
  2. /Quản lý Chất lượng
  3. /Commonwealth Bank và máy nộp tiền thông minh (Úc…
Số 502Quản lý Chất lượng

Commonwealth Bank và máy nộp tiền thông minh (Úc, 2012–2018): lỗi mã trong một bản cập nhật, 53.506 báo cáo giao dịch nộp trễ và khoản phạt 700 triệu đô la Úc

Commonwealth Bank (CBA) triển khai máy nộp tiền thông minh từ năm 2012. Một bản cập nhật phần mềm cuối năm 2012 có lỗi mã khiến máy không tạo báo cáo bắt buộc cho các khoản nộp tiền mặt từ 10.000 đô la Úc. Lỗi tồn tại tới năm 2015, làm 53.506 báo cáo giao dịch bị nộp trễ cho AUSTRAC. Năm 2018, CBA chấp nhận khoản phạt 700 triệu đô la Úc. Bài học về chất lượng: kiểm thử phải bao gồm cả đầu ra tuân thủ, không chỉ chức năng khách hàng nhìn thấy.

HP
Nguyễn Thu Hà, PMP
29/09/2026
4 phút đọc 0 lượt xem
Commonwealth Bank và máy nộp tiền thông minh (Úc, 2012–2018): lỗi mã trong một bản cập nhật, 53.506 báo cáo giao dịch nộp trễ và khoản phạt 700 triệu đô la Úc
Bình luận0

Bối cảnh thực tế

Máy nộp tiền thông minh (Intelligent Deposit Machine – IDM) của CBA cho phép nộp tiền mặt và séc, ghi có ngay vào tài khoản, tiền dùng được để chuyển đi ngay, kể cả ra nước ngoài, và ban đầu không có hạn mức nộp hằng ngày. Theo luật chống rửa tiền của Úc, mọi giao dịch tiền mặt từ 10.000 đô la Úc phải được báo cáo cho AUSTRAC (cơ quan tình báo tài chính Úc) bằng báo cáo giao dịch vượt ngưỡng.

Theo thông cáo của CBA, hồ sơ khởi kiện của AUSTRAC và báo chí công nghệ Úc:

  • IDM được đưa vào sử dụng năm 2012. AUSTRAC cho rằng CBA không đánh giá rủi ro rửa tiền và tài trợ khủng bố của IDM trước khi triển khai, và chỉ làm việc này khoảng ba năm sau.
  • Một bản cập nhật phần mềm cuối năm 2012 có lỗi mã khiến IDM không tạo báo cáo cho các khoản nộp từ 10.000 đô la Úc. CBA cho biết lỗi lộ ra năm 2015; ngân hàng báo AUSTRAC trong vòng một tháng, nộp bổ sung báo cáo và sửa mã. Từ tháng 9/2015, IDM báo cáo đúng.
  • Hệ quả: 53.506 báo cáo giao dịch vượt ngưỡng từ tháng 11/2012 đến tháng 9/2015 bị nộp trễ. CBA cho biết khoảng 53.000 lỗi báo cáo trong đơn kiện bắt nguồn từ lỗi mã này.
  • AUSTRAC khởi kiện tại Toà án Liên bang ngày 3/8/2017. Ngày 4/6/2018, hai bên thống nhất mức phạt dân sự 700 triệu đô la Úc cùng 2,5 triệu chi phí pháp lý — gần gấp đôi khoản 375 triệu CBA đã dự phòng trước đó.
  • CBA cũng thừa nhận các vi phạm khác: 149 báo cáo giao dịch đáng ngờ nộp trễ hoặc không nộp, giám sát giao dịch không hoạt động như thiết kế với một số tài khoản từ 10/2012 đến 10/2015, và chưa tuân thủ yêu cầu đánh giá rủi ro IDM trong 14 lần.
  • Ngân hàng cho biết đã chi hơn 400 triệu đô la Úc cho hệ thống, quy trình và nhân sự chống tội phạm tài chính, và áp hạn mức nộp tiền mặt qua IDM 10.000 đô la Úc mỗi ngày cho mỗi tài khoản.

Sơ đồ nguyên nhân: bản cập nhật phần mềm cuối 2012 có lỗi mã, không có kiểm thử hồi quy cho đầu ra báo cáo tuân thủ, không có đối soát số giao dịch vượt ngưỡng với số báo cáo, chưa đánh giá rủi ro trước triển khai; dẫn tới 53.506 báo cáo nộp trễ từ 11/2012 đến 9/2015 và mức phạt 700 triệu đô la Úc năm 2018

Phân tích nguyên nhân theo chuẩn PMP

  • Yêu cầu tuân thủ không nằm trong bộ kiểm thử hồi quy

    Máy vẫn nhận tiền, ghi có đúng, khách hàng không thấy gì bất thường. Thứ bị hỏng là một đầu ra "vô hình" — báo cáo gửi cơ quan quản lý. Nếu bộ kiểm thử chỉ kiểm tra chức năng khách hàng dùng, lỗi loại này sẽ lọt qua mọi bản phát hành.

  • Không có kiểm soát đối soát độc lập

    Một phép so sánh đơn giản — số giao dịch tiền mặt từ 10.000 đô la Úc trong ngày với số báo cáo đã gửi — sẽ phát hiện lỗi ngay ngày đầu. Thiếu kiểm soát chất lượng ở đầu ra cho phép lỗi âm thầm tồn tại gần ba năm.

  • Đánh giá rủi ro sản phẩm bị lùi sau triển khai

    Theo AUSTRAC, việc đánh giá rủi ro rửa tiền của IDM chỉ được làm khoảng ba năm sau khi đưa máy vào dùng. Khi rủi ro chưa được phân tích, các yêu cầu chất lượng tương ứng (báo cáo, giám sát, hạn mức) cũng không được xác định đầy đủ.

  • Chi phí của chất lượng kém tăng theo thời gian phát hiện

    Một lỗi mã có thể sửa trong vài ngày đã trở thành hơn 53.000 vi phạm và khoản phạt 700 triệu đô la Úc vì tồn tại quá lâu. Đây là ví dụ rõ về chi phí thất bại bên ngoài trong mô hình chi phí chất lượng.

Lẽ ra PM nên làm gì

  1. 1

    Bước 1: Đưa yêu cầu pháp lý vào ma trận truy vết yêu cầu

    Mỗi nghĩa vụ báo cáo được ghi thành yêu cầu, có ca kiểm thử tự động tương ứng và chạy lại trong mọi bản cập nhật, kể cả bản vá nhỏ.

  2. 2

    Bước 2: Xây kiểm soát đối soát hằng ngày

    So sánh tự động số giao dịch thuộc diện báo cáo với số báo cáo đã gửi; lệch là cảnh báo cho bộ phận tuân thủ trong vòng 24 giờ.

  3. 3

    Bước 3: Phân cấp mức kiểm thử theo loại đầu ra

    Không phải lỗi nào cũng có hậu quả như nhau:

    • Đầu ra hiển thị

      Giao diện, thông báo cho khách hàng: kiểm thử chức năng và người dùng thử.

    • Đầu ra tài chính

      Số dư, ghi có, phí: kiểm thử hồi quy tự động và đối soát số liệu.

    • Đầu ra pháp lý

      Báo cáo bắt buộc gửi cơ quan quản lý: ca kiểm thử bắt buộc, bộ phận tuân thủ ký xác nhận trước khi phát hành, đối soát hằng ngày sau phát hành.

PM Takeaway (Bài học rút ra)

Chất lượng của một sản phẩm tài chính gồm cả những gì khách hàng không nhìn thấy. PM cần biến nghĩa vụ tuân thủ thành yêu cầu có thể kiểm thử, và có kiểm soát đối soát để lỗi bị phát hiện trong vài ngày chứ không phải vài năm.

Nguồn tham khảo

  • Commonwealth Bank — CBA and AUSTRAC resolve AML/CTF proceedings (04/06/2018)
  • iTnews — CBA blames coding error for alleged money laundering (07/08/2017)
  • iTnews — CBA agrees to $700m penalty in ATM fraud case (04/06/2018)
#Quản lý chất lượng#Ngân hàng#Kiểm thử hồi quy#tuan-thu#Chống rửa tiền#Phát hành phần mềm

Nguồn: Commonwealth Bank — CBA and AUSTRAC resolve AML/CTF proceedings (04/06/2018) ↗ (mở trong thẻ mới)

Trắc nghiệm tình huống PMP

Câu 1/1
Nhóm của bạn chuẩn bị phát hành bản vá nhỏ cho phần mềm máy giao dịch tự động. Bộ kiểm thử hồi quy chỉ bao gồm các luồng khách hàng: nộp tiền, rút tiền, in biên lai. Máy còn tự động gửi báo cáo giao dịch lớn cho cơ quan quản lý. PM nên làm gì trước khi phát hành?

Bạn chọn phương án nào?

Nếu là PM sản phẩm IDM năm 2012, bạn ưu tiên khoản đầu tư chất lượng nào?

Tình huống này hữu ích với bạn?

Bình luận0

Bình luận (0)

Đăng nhập để tham gia thảo luận.

Tình huống tương tự

Số 483Quản lý Chất lượng

Vineyard Wind (2024): cánh tuabin gió ngoài khơi gãy vì lỗi sản xuất, mảnh vỡ dạt vào bãi biển và 150 cánh phải kiểm tra lại

Ngày 13/7/2024, một cánh dài 107 m của tuabin GE Vernova tại Vineyard Wind 1 (Massachusetts) bị gãy, mảnh sợi thuỷ tinh dạt vào bãi biển Nantucket. BSEE đình chỉ phát điện toàn trang trại. GE Vernova kết luận nguyên nhân là liên kết keo không đủ trong sản xuất — lỗi mà khâu đảm bảo chất lượng lẽ ra phải phát hiện — và kiểm tra lại khoảng 150 cánh cùng nhà máy. Bài học về kiểm soát chất lượng tại nguồn.

0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận29/10/2026
Số 381Quản lý Chất lượng

NASDAQ và IPO Facebook (2012): giới hạn thiết kế của hệ thống khớp lệnh và quyết định mở giao dịch khi chưa hiểu nguyên nhân gốc

Trong phiên IPO của Facebook ngày 18/5/2012, hệ thống khớp lệnh mở cửa (cross) của NASDAQ gặp giới hạn thiết kế. Lãnh đạo tin rằng vài dòng mã đã sửa xong và cho giao dịch tiếp tục khi chưa hiểu nguyên nhân gốc; hơn 30.000 lệnh bị kẹt hơn hai giờ. SEC phạt NASDAQ 10 triệu USD — mức cao nhất với một sở giao dịch khi đó. Bài học về quản lý chất lượng và ra quyết định khi có sự cố.

0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận22/10/2026
Số 369Quản lý Chất lượng

Cloudflare 18/11/2025: một thay đổi quyền truy vấn cơ sở dữ liệu làm tệp cấu hình phình gấp đôi và sự cố lớn nhất kể từ 2019

Một thay đổi về quyền truy cập cơ sở dữ liệu khiến truy vấn sinh tệp đặc trưng (feature file) cho Bot Management trả về dòng trùng lặp. Tệp vượt giới hạn 200 đặc trưng, làm proxy lõi bị panic và trả lỗi 5xx trên phần lớn mạng Cloudflare gần sáu giờ. Bài học về kiểm soát chất lượng cho cấu hình do chính hệ thống nội bộ sinh ra.

1 lượt thích 0 lượt đánh giá hữu ích 0 bình luận22/10/2026

Nội dung

Bối cảnh thực tếPhân tích nguyên nhân theo chuẩn PMPLẽ ra PM nên làm gìPM Takeaway (Bài học rút ra)Nguồn tham khảoTrắc nghiệmBình chọn
Quảng cáoBộ đề thi thử PMP (mẫu)