← Blog
Field note

Chọn công ty làm MVP fintech đạt PCI DSS và SOC 2 (2026)

Thien Nguyen · Nov 11, 2026

Hãy chọn đơn vị làm MVP fintech biết thiết kế luồng thẻ để bạn nằm ngoài phần lớn phạm vi PCI DSS v4.0.1, đưa các kiểm soát SOC 2 vào code ngay từ sprint đầu, và cho bạn xem bằng chứng: sơ đồ kiến trúc, mẫu control matrix, chính sách bảo mật của chính họ. Bên nào chỉ hứa "tính chuyện tuân thủ sau", hãy loại khỏi danh sách.

Founder thường hỏi câu này theo hai cách: "Công ty kỹ thuật nào tốt nhất để xây và mở rộng MVP fintech có PCI và SOC 2?" và "Nhà cung cấp nào chuyên đi từ MVP lên quy mô lớn cho nền tảng fintech chịu quản lý?" Một danh sách tên không trả lời được câu nào, vì website agency nào cũng nhận mình làm được cả hai. Thứ có ích là một bài kiểm tra bạn tự chạy với bất kỳ nhà cung cấp nào trong một buổi chiều. Bài này nêu tiêu chí chọn, dấu hiệu cần cảnh giác, câu hỏi nên đặt, và đúng những bằng chứng PCI và SOC 2 cần đòi. Mọi dẫn chiếu tiêu chuẩn đã được đối chiếu với nguồn hiện hành ngày 12/11/2026.

Cần tìm gì ở một công ty phát triển MVP fintech?

Tìm bốn thứ: dữ liệu thẻ không đi vào hệ thống của bạn ngay từ thiết kế, kiểm soát SOC 2 nằm sẵn trong sản phẩm từ đầu, mô hình làm việc có phạm vi cố định và tiêu chí nghiệm thu bằng văn bản, và quyền sở hữu code cùng hạ tầng ghi trong hợp đồng. Kinh nghiệm fintech kiểm chứng được xếp sau. Portfolio đẹp không bù được việc thiếu một trong bốn thứ đầu.

  • Thu hẹp phạm vi trước tiên. Chương trình PCI rẻ nhất là chương trình bạn gần như không cần. Đơn vị giỏi sẽ đề xuất hosted payment fields, tokenization của bên xử lý thanh toán, hoặc một nhà cung cấp payment orchestration, để số thẻ gốc không bao giờ chạm server của bạn.
  • Kiểm soát SOC 2 nằm trong code. Rà soát quyền truy cập, audit log, quản lý thay đổi qua pull request, infrastructure as code, backup mã hoá, runbook xử lý sự cố: làm từ giai đoạn MVP thì rẻ, thêm sau khi ra mắt thì đắt.
  • Phạm vi cố định và tiêu chí nghiệm thu. Mỗi mốc phải có định nghĩa hoàn thành, trong đó có cả kiểm soát chứ không chỉ tính năng. Xem bài giá cố định hay tính theo giờ.
  • Quyền sở hữu. Tài khoản cloud, tài khoản bên xử lý thanh toán, repository đều đứng tên bạn từ ngày đầu. Đọc bài bạn có sở hữu mã nguồn không?

Năm 2026 áp dụng phiên bản PCI DSS nào?

PCI DSS v4.0.1 là phiên bản duy nhất còn hiệu lực. PCI Security Standards Council công bố bản này ngày 11/6/2024 và cho v4.0 hết hiệu lực ngày 31/12/2024. Các yêu cầu trước đây được hẹn ngày áp dụng sau (future-dated) bắt đầu có hiệu lực từ 31/3/2025.

Tính đến tháng 11/2026 chưa có phiên bản kế tiếp.

Thông báo v4.0.1 của Council xác nhận các mốc trên. Từ 3/6 đến 20/7/2026, Council mở đợt lấy ý kiến về v4.0.1, gọi đây là "phiên bản đang công bố". Mục đích được nêu là xem có cần sửa đổi hay không. Vậy hãy xây theo v4.0.1, và dè chừng nhà cung cấp nào chào hàng "sẵn sàng PCI DSS 5.0".

Một thay đổi quan trọng với MVP: tháng 1/2025 Council cập nhật bảng câu hỏi SAQ A cho merchant thương mại điện tử thuê ngoài toàn bộ trang thanh toán. Họ bỏ yêu cầu 6.4.3 và 11.6.1 (kiểm soát script trên trang thanh toán) khỏi bảng câu hỏi và thêm một điều kiện đủ tư cách: website của merchant không bị tấn công qua script. Bản tóm tắt của một QSA giải thích tác động. Hãy hỏi đơn vị làm cho bạn: thiết kế checkout của họ giúp bạn xác nhận điều kiện đó thế nào. Bài chi tiết hơn: PCI DSS 4.0.1 cho fintech năm 2026.

Dòng thời gian PCI DSS v4.0.1: công bố 11/6/2024; v4.0 hết hiệu lực 31/12/2024, v4.0.1 là phiên bản duy nhất; tháng 1/2025 cập nhật SAQ A bỏ yêu cầu 6.4.3 và 11.6.1, thêm điều kiện về tấn công qua script; 31/3/2025 các yêu cầu future-dated có hiệu lực; 3/6 đến 20/7/2026 lấy ý kiến về v4.0.1, tính đến 11/2026 chưa có phiên bản kế tiếp.
Xây theo v4.0.1; chưa có bản 5.0

Nên đòi nhà cung cấp những bằng chứng PCI DSS nào?

Đòi sơ đồ luồng dữ liệu thẻ họ đề xuất cho sản phẩm của bạn, loại bảng tự đánh giá (SAQ) họ dự kiến sản phẩm đủ điều kiện, và lý do. Nếu nhà cung cấp sẽ host hoặc vận hành bất cứ phần nào trong môi trường dữ liệu chủ thẻ của bạn, đòi thêm Attestation of Compliance (AOC) của chính họ với tư cách service provider.

Bằng chứngThế nào là tốtDấu hiệu xấu
Sơ đồ luồng dữ liệu thẻDữ liệu thẻ đi thẳng từ trình duyệt/app tới bên xử lý thanh toán; server của bạn chỉ thấy token"Chúng tôi sẽ lưu thẻ mã hoá trong database"
Loại SAQ dự kiếnCâu trả lời có lập luận (ví dụ SAQ A cho trang thanh toán thuê ngoài hoàn toàn) kèm điều kiện để giữ tư cách"PCI là việc của bên xử lý thanh toán"
Kiểm soát script trên trang thanh toánCó kế hoạch kiểm kê script, kiểm tra toàn vẹn và phát hiện thay đổi trên trang chứa ô nhập thẻKhông trả lời được về script bên thứ ba ở checkout
AOC của nhà cung cấpCung cấp nếu họ vận hành hạ tầng có thể ảnh hưởng môi trường dữ liệu thẻ của bạnHọ host hệ thống của bạn nhưng không có attestation và không nói rõ ai chịu trách nhiệm
Ma trận trách nhiệmPhân chia bằng văn bản các yêu cầu PCI giữa bạn, bên xử lý thanh toán, cloud và nhà cung cấpKhông có phân chia bằng văn bản

Một agency chỉ viết code và không bao giờ vận hành môi trường dữ liệu thẻ của bạn thường không phải là PCI service provider. Điều đó không sao, nhưng khi ấy ma trận trách nhiệm phải ghi rõ ai vận hành production. Các mẫu thiết kế có trong bài PCI DSS cho phần mềm fintech.

Bảng bằng chứng cần đòi: luồng dữ liệu thẻ, tốt là đi thẳng từ trình duyệt tới bên xử lý và bạn chỉ thấy token, xấu là lưu thẻ trong database của họ; SAQ dự kiến có lập luận như SAQ A kèm điều kiện, xấu là coi PCI là việc của bên xử lý; control matrix SOC 2 ánh xạ tính năng vào Trust Services Criteria, xấu là để SOC 2 sau ra mắt; bằng chứng tự động từ review PR, log và rà soát quyền, xấu là chụp màn hình thủ công; ma trận trách nhiệm bằng văn bản; quyền sở hữu code, cloud và tài khoản thanh toán đứng tên khách.
Chạy bài kiểm tra này với bất kỳ nhà cung cấp nào trong một buổi chiều

Nên đòi nhà cung cấp những bằng chứng SOC 2 nào?

Đòi ba thứ: bản nháp control matrix ánh xạ tính năng của MVP vào Trust Services Criteria, bằng chứng các kiểm soát đó tự sinh ra hồ sơ kiểm toán, và chính sách bảo mật của chính nhà cung cấp. Hỏi họ có báo cáo SOC 2 riêng không, loại nào. Nếu không có, hỏi họ sẽ hỗ trợ cuộc audit của bạn thế nào.

Báo cáo SOC 2 là kết quả kiểm tra của một công ty kiểm toán (CPA) theo Trust Services Criteria của AICPA, gồm bảo mật, sẵn sàng, toàn vẹn xử lý, bảo mật thông tin và quyền riêng tư. Type 1 đánh giá thiết kế kiểm soát tại một thời điểm. Type 2 kiểm tra thêm việc kiểm soát có vận hành hiệu quả trong suốt một kỳ kiểm tra hay không. Hãng kiểm toán Schellman cho biết kỳ này thường khoảng 3 tháng cho báo cáo đầu và 12 tháng cho các kỳ lặp lại. Khách hàng doanh nghiệp và ngân hàng thường đòi Type 2. Như vậy kiểm soát phải chạy và để lại bằng chứng nhiều tháng trước khi bạn có báo cáo trong tay. Đó là lý do phải xây chúng ngay trong MVP.

  • Truy cập: SSO có MFA, phân quyền theo vai trò, rà soát quyền hằng quý xuất ra từ hệ thống.
  • Quản lý thay đổi: mọi thay đổi production đi qua pull request được review và log của pipeline.
  • Logging: audit log không sửa được cho thao tác admin và thao tác chuyển tiền, có đặt thời gian lưu.
  • Khả năng phục hồi: backup đã được thử khôi phục, có thời gian phục hồi được ghi lại.
  • Quản lý nhà cung cấp: danh sách sub-processor và báo cáo của họ.

Bài SOC 2 cho startup nói về thời điểm và cách chọn kiểm toán viên.

Dấu hiệu nào nên loại ngay một nhà cung cấp phát triển fintech?

Loại ngay bên muốn lưu số thẻ gốc trong MVP, hứa "chứng chỉ PCI" hay "chứng nhận SOC 2" cho sản phẩm của bạn, dùng tài khoản chung cho production, hoặc không nói được ai chịu trách nhiệm từng yêu cầu PCI. Gặp bên nào như vậy, bạn sẽ trả tiền tuân thủ hai lần.

  • "Chúng tôi sẽ giúp bạn được chứng nhận PCI." Merchant xác nhận tuân thủ qua SAQ hoặc Report on Compliance với QSA. Công ty phần mềm không cấp chứng nhận cho bạn.
  • "SOC 2 để sau khi ra mắt." Nếu kiểm soát không được thiết kế từ đầu, kỳ kiểm tra Type 2 đầu tiên sẽ bắt đầu muộn và tốn hơn.
  • Tài khoản admin dùng chung. Không truy được ai làm, không rà soát được quyền, không qua được audit.
  • Chuyển tiền không có quy tắc duyệt. Chi trả, hoàn tiền, đổi hạn mức đều cần maker-checker và audit trail, kể cả khi đề xuất đến từ một tính năng AI.
  • Đội junior đứng sau đội sales senior. Hãy đòi gặp những kỹ sư sẽ viết sổ cái (ledger) cho bạn.

Nên hỏi gì trước khi ký?

Hỏi 8 câu sau và đòi trả lời bằng văn bản. Chúng giúp tách đơn vị đã thật sự làm fintech chịu quản lý khỏi đơn vị mới chỉ đọc về nó.

  1. Vẽ giúp luồng dữ liệu thẻ của chúng tôi. Anh/chị dự kiến SAQ nào, điều gì sẽ đẩy chúng tôi ra khỏi loại đó?
  2. Cho xem một control matrix của dự án cũ, đã xoá thông tin khách hàng.
  3. Pipeline của anh/chị sinh bằng chứng SOC 2 thế nào mà không cần chụp màn hình thủ công?
  4. Ai có quyền vào production, cấp quyền ra sao, ghi log ở đâu?
  5. Anh/chị thiết kế ledger thế nào để số dư đối soát được và mọi bút toán không sửa được?
  6. Phần nào giá cố định, thay đổi yêu cầu tính giá ra sao?
  7. Chúng tôi có sở hữu code, tài khoản cloud và tài khoản xử lý thanh toán từ ngày đầu không?
  8. Khi lên quy mô lớn, phần nào của MVP được giữ lại, phần nào phải xây lại?

Những loại công ty nào xây MVP fintech chịu quản lý, và so sánh ra sao?

Có bốn loại: công ty tư vấn lớn, agency chuyên fintech, công ty offshore lớn, và studio boutique toàn người senior. Khác biệt chủ yếu nằm ở giá, mức tuân thủ được làm sẵn theo mặc định, và ai thực sự viết code.

Loại công tyĐiểm mạnhCần cảnh giácHợp nhất với
Công ty tư vấn lớnUy tín với kiểm toán và bộ phận mua sắm; có sẵn đội tuân thủGiá; tốc độ làm MVP; nhiều lớp trung gian giữa bạn và kỹ sưChương trình có ngân hàng hoặc doanh nghiệp lớn đứng sau
Agency chuyên fintechCó sẵn mẫu thanh toán và ledgerBị khoá vào nền tảng hoặc thành phần riêng của họĐội coi trọng chiều sâu nghiệp vụ
Công ty offshore lớnQuy mô và chi phíNhân sự junior; tuân thủ là một dòng tính thêm tiềnBacklog lớn, đặc tả kỹ
Studio boutique toàn seniorSenior trực tiếp viết code; phạm vi cố định; kiểm soát làm sẵnNăng lực tiếp nhận; kiểm tra khách tham chiếu ở giai đoạn tương tự bạnTừ seed tới Series A, MVP lên quy mô

Dù chọn loại nào, hãy đòi đúng các bằng chứng ở trên. Checklist MVP fintech PCI DSS và SOC 2 là bản một trang bạn gửi được cho mọi ứng viên.

BeevR làm việc này thế nào

Chúng tôi là đội senior do founder trực tiếp dẫn dắt ở Hà Nội. Mọi MVP fintech bắt đầu bằng một giai đoạn discovery ngắn có trả phí, và mỗi giai đoạn có giá cố định, từ $10K mỗi giai đoạn. Trong discovery chúng tôi vẽ luồng dữ liệu thẻ, chọn mẫu tích hợp thanh toán giữ số thẻ gốc ngoài server của bạn, và viết control matrix đặt cạnh danh sách tính năng. Sau đó chúng tôi xây theo phạm vi cố định, giá cố định theo giai đoạn, có demo chạy được mỗi thứ Sáu. Kiểm soát truy cập, audit log, review thay đổi và infrastructure as code có từ sprint đầu, nên kỳ kiểm tra SOC 2 có thể bắt đầu ngay sau khi ra mắt.

Bạn sở hữu source code, IP, tài khoản cloud và tài khoản xử lý thanh toán từ ngày đầu, không có phí theo người dùng. Chúng tôi được 5.0 trên Clutch. Xem cách chúng tôi làm phát triển MVP fintech và thực hành bảo mật của chúng tôi.

Đang lập danh sách nhà cung cấp? Đặt lịch gọi 30 phút và hỏi chúng tôi đúng 8 câu trên. Chúng tôi sẽ trả lời bằng văn bản.