Phát triển phần mềm fintech: phạm vi, tuân thủ và mô hình triển khai

Tốc độ không phải vấn đề của kỹ thuật fintech. Tốc độ chưa được tính giá mới là vấn đề, và hóa đơn đến ở bốn chỗ có thể đoán trước.

Chỉ là thông tin chung, cập nhật tại thời điểm đăng bài, không phải tư vấn pháp lý hay quy định. Ghi chú đầy đủ ở cuối bài.

Các đội fintech thường đúng khi muốn đi nhanh. Vấn đề không nằm ở tốc độ; vấn đề là hóa đơn cho tốc độ đến một địa chỉ mà không ai ghi lại: lần tích hợp đối tác đầu tiên, câu hỏi kiểm toán đầu tiên, bước tăng khối lượng đầu tiên biến một dòng ngoại lệ nhỏ giọt thành một hàng đợi không có người phụ trách.

Phát triển phần mềm fintech vẫn chạy trên những hệ thống xử lý danh tính, chuyển tiền, dữ liệu khách hàng, đối soát và các ngoại lệ vận hành, và chúng định hình kiến trúc từ rất lâu trước danh sách tính năng. Bốn ranh giới quyết định hóa đơn đến vào tuần nào. Với phía ngân hàng của cùng bài toán này, xem bài tích hợp core banking cho hệ thống phải chạy liên tục.

Ranh giới 1: ranh giới sản phẩm và workflow của fintech

Hãy gọi tên người dùng, giao dịch hoặc quyết định mà hệ thống hỗ trợ, rồi lần theo nó ra ngoài: dữ liệu thượng nguồn và ai sở hữu nguồn đó, hành động hạ nguồn và những gì phụ thuộc vào nó, đường xử lý ngoại lệ khi giao dịch không hoàn tất, và người sở hữu ngoại lệ đó theo vai trò.

Đây là sự khác biệt giữa một product backlog và một danh sách màn hình không có mô hình vận hành đứng sau, một sự khác biệt vô hình cho đến khi sản phẩm đã chạy thật và ai đó phải giải trình về một giao dịch bị kẹt lúc chín giờ tối thứ Sáu.

Ranh giới 2: ranh giới tích hợp fintech và hành vi khi lỗi

Một dịch vụ fintech có thể phụ thuộc vào nhà cung cấp thanh toán, các kênh ngân hàng, kiểm tra danh tính và KYC, dịch vụ dữ liệu, CRM và vận hành nội bộ. Mỗi phụ thuộc cần năm thứ được ghi lại trước khi bắt đầu xây dựng:

Hành vi khi lỗi quan trọng hơn số liệu uptime, vì nhà cung cấp hiếm khi hỏng một cách gọn gàng. Họ suy giảm: phản hồi chậm hơn, kết quả một phần, một webhook đến hai lần, một tệp settlement đến muộn thay vì mất. Điều khách hàng trải nghiệm vào ngày đó đã được quyết định bằng một lựa chọn thiết kế mà ai đó đưa ra từ nhiều tháng trước, hoặc đã không đưa ra. Với nền tảng thanh toán xuyên biên giới mà chúng tôi đã xây dựng cho một công ty fintech Hồng Kông, điều đó nghĩa là coi sổ cái lõi, các tài khoản đa tiền tệ và các kênh SWIFT, SEPA, ACH và FPS là một bài toán đối soát (reconciliation) duy nhất thay vì bốn tích hợp riêng rẽ.

Ranh giới 3: ranh giới dữ liệu và bằng chứng trong sản phẩm chịu quản lý

Hãy lập bản đồ dữ liệu cá nhân và dữ liệu giao dịch xuyên suốt dịch vụ và quyết định thứ gì phải được ghi log, lưu giữ, chỉnh sửa, xóa và cung cấp để rà soát, kể cả nơi vạch ranh giới giữa dữ liệu phát triển, kiểm thử và production, vốn là nơi phần lớn rủi ro lộ dữ liệu có thể tránh được bắt nguồn.

Với các sản phẩm xử lý dữ liệu cá nhân tại Hồng Kông, lập trường của chính khách hàng theo Pháp lệnh Dữ liệu Cá nhân (Quyền riêng tư) chi phối các quyết định đó. Nhiệm vụ kỹ thuật là làm cho lập trường đó thi hành được trong hệ thống và chứng minh được sau đó, thay vì mô tả nó trong một chính sách mà không thứ gì trong stack kiểm tra, chính là bài toán bằng chứng được nêu trong bài RegTech và AI thực sự giao thoa ở đâu.

Ranh giới 4: ranh giới phát hành và hỗ trợ trước production đầu tiên

Năm thứ cần được xác định trước bản phát hành production đầu tiên, không phải sau sự cố đầu tiên, khi chi phí thiết kế chúng cao nhất và những người liên quan mệt mỏi nhất:

Những chỗ dự án phát triển phần mềm fintech thường đi chệch

Qua các sản phẩm thanh toán, cho vay và lưu trữ giá trị, bốn khuôn mẫu chiếm phần lớn công việc làm lại mà chúng tôi được nhờ gỡ, và không cái nào lạ lùng.

Khuôn mẫu thứ nhất là một tích hợp được giả định thay vì được chứng minh. Sandbox của nhà cung cấp hành xử khác với production khi chịu tải, lỗi một phần và lệch đối soát, và một kế hoạch dựa trên hành vi sandbox thường nhận ra điều này ở sprint cuối trước ngày ra mắt.