Bạn có cần giấy phép ngân hàng để ra mắt một ứng dụng fintech?

"Bạn có cần giấy phép ngân hàng để ra mắt một ứng dụng fintech?" thực chất là ba câu hỏi khoác chung một chiếc áo. Bạn có nắm giữ tiền của khách hàng không? Bạn có chuyển tiền đó đi không? Và việc chuyển tiền ấy nằm dưới sự cho phép của cơ quan quản lý nào — của bạn, hay của người khác? Trả lời xong những câu này thì câu hỏi về giấy phép gần như tự có đáp án. Điều ngắn gọn mà nhiều đội ngũ bất ngờ: phần lớn ứng dụng fintech không bao giờ nắm giữ giấy phép ngân hàng, vì phần lớn ứng dụng fintech không bao giờ làm đúng việc mà giấy phép ngân hàng sinh ra để dành cho. Dưới đây là bản đồ của cả phổ giấy phép, không phải tư vấn pháp lý — mục tiêu là biết nên hỏi những câu nào trước khi có ai báo cho bạn thời hạn hay mức giá.

Giấy phép ngân hàng thực sự dành cho việc gì

Giấy phép ngân hàng đầy đủ — theo cách gọi của EU là giấy phép tổ chức tín dụng — cho phép một hoạt động cụ thể và được kiểm soát chặt: nhận tiền gửi từ công chúng và cho vay lại số tiền đó. Chính sự lệch kỳ hạn này, tức tài trợ các khoản vay dài hạn bằng số dư mà khách hàng có thể rút bất cứ lúc nào, là lý do ngân hàng phải chịu yêu cầu vốn nghiêm ngặt, nghĩa vụ bảo hiểm tiền gửi và một cơ quan giám sát đọc bảng cân đối của họ từng dòng. Nếu ứng dụng của bạn không nhận tiền gửi và cho vay dựa trên đó, gần như chắc chắn bạn không cần giấy phép ngân hàng. Bạn đang cần một thứ nhẹ hơn, nằm xa hơn trên phổ giấy phép — và cả câu chuyện nằm ở chính phổ giấy phép đó.

Phổ giấy phép: từ nặng nhất đến nhẹ nhất

Giấy phép tài chính được chia thành nhiều bậc. Trên cùng là tổ chức tín dụng — tức ngân hàng — được phép nhận tiền gửi và cho vay. Bên dưới là tổ chức tiền điện tử (EMI), được phát hành tiền điện tử: có thể lưu giữ giá trị của khách hàng và đưa vào thẻ hoặc ví, nhưng khoản float nắm giữ phải được bảo vệ — tách riêng, không đụng đến, tuyệt đối không cho vay. Thấp hơn nữa là tổ chức thanh toán (PI), được thực hiện thanh toán — khởi tạo chuyển khoản, thu hộ, chuyển tiền, thanh toán giao dịch thẻ (acquiring) — nhưng không được thiết kế để lưu giữ giá trị lâu dài; tiền đi qua chứ không nằm lại. Dưới cùng là đại lý hoặc nhà phân phối: không có giấy phép riêng, mà hoạt động dưới sự ủy quyền của một đơn vị được cấp phép đã đăng ký họ.

Quy luật là cứ xuống một bậc thì bớt đi một năng lực, kéo theo bớt một phần vốn và nghĩa vụ. Nhận tiền gửi là việc nặng nhất bạn có thể được phép làm; làm đại lý cho đơn vị có quyền đó là nhẹ nhất. Phần lớn ứng dụng fintech dành cho người dùng cá nhân — ví, thẻ, chuyển tiền, liên kết thanh toán — nằm trong khoảng EMI và tổ chức thanh toán, hoặc chạy trên nền một đối tác nắm giữ một trong các giấy phép đó. Rất ít sản phẩm cần phải là ngân hàng, và biết điều này sớm sẽ tránh được rất nhiều công sức đặt sai chỗ.

Cách nhanh để xác định vị trí của bạn: nếu khách hàng giữ số dư trong ứng dụng — ví họ nạp tiền, thẻ họ nạp trước — bạn đang ở lãnh địa tiền điện tử, vì lưu giữ giá trị chính là quyền định nghĩa một EMI. Nếu tiền chỉ đi qua — bạn khởi tạo chuyển khoản, thu hóa đơn, chuyển thẳng khoản chi trả — thì giấy phép tổ chức thanh toán là lựa chọn tự nhiên, do bạn hoặc đối tác nắm giữ. Nếu bạn không chạm vào tiền và chỉ hiển thị thông tin về các tài khoản mở ở nơi khác, thì ngay cả trường hợp này cũng có một dạng đăng ký nhẹ hơn riêng. Đứng càng cao thì vốn và sự giám sát đi kèm càng nhiều; mục tiêu thiết kế là không đứng cao hơn mức sản phẩm thực sự cần.

Thuê giấy phép: các mô hình đối tác

Bạn không nhất thiết phải tự nắm giấy phép mới xây dựng được sản phẩm. Cách phổ biến là thuê. Với mô hình ngân hàng bảo trợ (sponsor bank) hoặc Banking-as-a-Service, một ngân hàng hoặc EMI được cấp phép sẽ giữ tài khoản, phát hành IBAN và thẻ, đồng thời bảo vệ float; bạn xây ứng dụng trên API của họ và đưa trải nghiệm ra thị trường. Với mô hình đại lý, bạn đăng ký làm đại lý của một tổ chức thanh toán — hoặc nhà phân phối của một đơn vị phát hành tiền điện tử — và giấy phép của họ bao trùm hoạt động của bạn, cơ quan quản lý biết đến bạn thông qua họ. Hợp đồng khác nhau, nhưng sự thật bên dưới thì giống nhau: ở đâu đó trong hệ thống, có người nắm giấy phép. Câu hỏi duy nhất là người đó là bạn hay đối tác.

Ai chịu trách nhiệm phần nào

Thuê giấy phép không có nghĩa là thuê luôn trách nhiệm. Đơn vị được cấp phép là bên giải trình với cơ quan quản lý — về việc bảo vệ tiền khách hàng, giám sát phòng chống rửa tiền, và cách vận hành toàn bộ chương trình. Nhưng các nghĩa vụ ấy được chuyển xuống theo hợp đồng. Dùng giấy phép của đối tác, bạn vẫn phải làm KYC và onboarding, vẫn phải theo dõi giao dịch cho AML, vẫn phải tuân thủ hạn mức và báo cáo mà đối tác bị ràng buộc. Trách nhiệm không hẳn được thuê ngoài mà được phân chia: đối tác chịu trách nhiệm trước cơ quan quản lý, và buộc bạn bằng một hợp đồng đẩy phần lớn nghĩa vụ hằng ngày về phía bạn. Hãy đọc hợp đồng đó kỹ như cách bạn sẽ đọc giấy phép mà bạn đã chọn không xin.

Giấy phép là quyền nắm giữ hoặc chuyển tiền của người khác. Phần mềm là cách tiền đó được ra lệnh, đối soát và hiển thị lại cho khách hàng. Bạn có thể mua từ một nhà cung cấp hoặc từ hai — nhưng lúc nào cũng phải mua cả hai.

Phần mềm và giấy phép là hai khoản mua riêng biệt

Đây là nhận định làm thay đổi cách sắp xếp toàn bộ dự án. Với khách hàng, một ứng dụng thanh toán trông như một thứ duy nhất, nhưng thực ra là hai thứ gắn vào nhau: quyền được cấp phép để nắm giữ hoặc chuyển tiền, và phần mềm ra lệnh cho việc chuyển tiền, giữ sổ cái, đối soát các khoản có, và hiển thị số dư trên màn hình. Hai thứ này được tìm nguồn riêng. Bạn có thể tự nắm giấy phép và mua phần mềm; nắm giấy phép và tự xây phần mềm; thuê quyền qua đối tác và mua phần mềm chạy trên đó; hoặc lấy cả hai từ một nhà cung cấp đã đóng gói chung. Cả bốn đều bình thường. Điều không bình thường — và lặng lẽ làm dự án mất hàng tháng — là nhầm lẫn giữa hai thứ: đi tìm “giấy phép ngân hàng” trong khi thứ bạn cần là một đối tác BaaS cộng với một ứng dụng, hoặc đi tìm ứng dụng với giả định rằng giấy phép đã được gắn liền sẵn.

Nhìn chúng như hai khoản mua riêng giúp mọi thứ rõ ràng hơn vì bạn có thể định giá và lập lịch cho từng khoản độc lập. Phần mềm được đánh giá theo giá trị của nó — luồng onboarding có chạy tốt không, sổ cái có chính xác không, đội vận hành có thực sự điều hành được không — còn giấy phép được đánh giá theo thẩm quyền pháp lý, cơ chế bảo vệ tiền và điều khoản. Protocore Pay (/products/pay) là ví dụ về lớp phần mềm đứng riêng: một nền tảng ứng dụng whitelabel kèm bảng điều khiển cho vận hành, chạy trên bất kỳ hạ tầng được cấp phép nào bạn mang đến. Nó không phải giấy phép, và không phần mềm nào là giấy phép — đó chính là lý do giấy phép luôn là một hạng mục riêng trong kế hoạch.

Những câu hỏi nên hỏi mọi nhà cung cấp nền tảng

Dù ai đang chào bạn một nền tảng “ra mắt fintech của bạn”, thì cùng một danh sách ngắn này sẽ gạt bỏ phần lớn sự mập mờ. Sản phẩm của bạn có bao gồm giấy phép không, hay tôi tự mang giấy phép đến? Nếu có, đó là giấy phép của ai, ở những quốc gia nào, và tôi là khách hàng trực tiếp của đơn vị đó hay của đại lý? Ai bảo vệ tiền khách hàng, và tiền được giữ ở đâu? Ai được nêu tên với cơ quan quản lý về phòng chống rửa tiền — bạn, đối tác hay tôi? Những nghĩa vụ nào rơi vào tôi theo hợp đồng dù giấy phép không phải của tôi? Và nếu quan hệ đối tác chấm dứt, tiền và dữ liệu của khách hàng tôi sẽ ra sao? Các câu trả lời sẽ nhanh chóng phân loại nhà cung cấp thành bên bán phần mềm, bên bán lại giấy phép của đối tác, và bên thực sự đóng gói cả hai — đồng thời cho bạn biết mình đang nói chuyện với loại nào.

Điều đáng yên tâm là: phần lớn ứng dụng ra mắt với phần mềm cộng giấy phép của đối tác, rồi chỉ chuyển sang giấy phép riêng khi quy mô giao dịch, biên lợi nhuận hoặc chiến lược khiến khoản vốn và đội ngũ tuân thủ trở nên đáng giá. Biết mình thực sự cần bậc nào — và phần mềm với giấy phép được mua ở hai hạng mục riêng — là đã xong phần lớn cuộc chiến. Phần còn lại là đặt những câu hỏi trên và đọc kỹ câu trả lời. Nội dung này không phải tư vấn pháp lý, ngưỡng và tên gọi các loại hình khác nhau tùy thẩm quyền pháp lý; hãy coi đây là tấm bản đồ mang theo khi trao đổi với cơ quan quản lý hoặc cố vấn, chứ không thay thế họ.