Define the activity before the architecture
Publishing financial information, making recommendations, arranging transactions and holding funds are different activities. Document the service, customers, money flows and parties involved. The responsible legal and compliance advisers should establish the applicable permissions and obligations before a development team assumes a particular operating model is acceptable.
Trace an approved requirement into product evidence
For an example financial workflow, an adviser has specified separate maker and approver roles for a sensitive change. Developers need concrete states and tests to demonstrate that separation. This is an implementation example, not a licensing assessment.
| Scenario | Expected record |
|---|---|
| Maker submits a change | Pending state with original values, proposed values and maker ID |
| Maker tries to approve the same change | Denied operation with an audit event |
| Authorised approver rejects the request | Original values preserved; rejection reason and actor recorded |
Turn obligations into reviewable requirements
A requirement should identify the action, role, record and evidence needed. Examples to evaluate include approval steps, identity checks, transaction history, access controls and reconciliation. Avoid adding a “compliant” badge to a feature without stating which requirement it satisfies and who accepts the evidence.
Separate testing from authorisation
A prototype or controlled trial can reveal operational issues, but it does not automatically authorise a regulated activity. Where relevant, review official regulator information such as the HKMA’s fintech materials with your advisers. Agree what can be tested, with whom and using which data before connecting live customers or funds.
Before you proceed
- Document the business activity and money flows.
- Assign an accountable legal or compliance owner.
- Link each control to an agreed requirement and acceptance test.
