The interface name does not determine the nature of the business
An API may merely display third-party quotes, or it may receive orders and then select counterparties on the customer's behalf, split orders and initiate transfers. It is necessary to clarify: does the customer establish a service relationship directly with a licensed institution? Who can modify the receiving address, cancel orders or release payments? Who bears responsibility for making up shortfalls if a transaction fails? These questions reveal more clearly than the statement that "the funds did not pass through the company's bank account" whether the company is actually selling software or providing financial services.
Not holding assets does not necessarily mean being outside the scope of regulation
When Singapore's MAS expanded the scope of payment services regulation in 2024, it expressly included certain activities facilitating the transfer or exchange of funds or digital payment tokens without holding the funds or tokens. Therefore, the fact that the server merely transmits instructions and assets move directly from the customer's wallet to a third-party wallet is not a globally applicable licence-free structure. By contrast, the US FinCEN guidance on software development distinguishes between merely developing and selling software and using software to operate a money transmission business; that conclusion addresses only its specific regulatory scope and cannot substitute for the assessment of other states or countries.
Testing the boundary with a hypothetical change
Suppose a merchant originally placed orders independently on a third-party page, and the software only synchronised order status; later, to "optimise the experience", the team had customers uniformly accept terms on its own page, with the platform automatically selecting the quoting party and guaranteeing the exchange rate and arrival of funds. Even if the underlying payment address remains unchanged, the newly added customer commitments, order control and performance arrangements may also change the legal characterisation. The technical team's permission design, product copy and contracts must be reviewed together, rather than checking only the receiving account after development is complete.
Turning technical boundaries into verifiable evidence
If the intention is to operate on a purely technical model, the company should retain data-flow and instruction-flow descriptions, an interface permission list and division-of-labour contracts with service providers, and confirm that an applicable exclusion or exemption basis genuinely exists locally. Do not describe the real business as a different business in order to reduce regulatory costs; customers should know who provides the exchange, custody and payment services. New features added after launch should also undergo change review, especially features such as unified balances, automatic currency conversion and platform signing on behalf of customers. During review, do not look only at front-end flowcharts; have technical personnel demonstrate administrator permissions, key sharding, contract upgrades and manual release functions, to confirm that the division of labour on paper matches actual capabilities.
Recommended actions
- List the read and write permissions of each API one by one, and check whether the platform can independently or jointly change the destination of assets.
- Verify whether the actual service provider stated in the interface, terms and customer service commitments is consistent.
- For the "purely technical" conclusion, create a record of the applicable jurisdictions, specific provisions and functional boundaries.
Information note: This article provides general information only and does not replace legal advice based on specific facts.
