First, ask the client to whom it is actually purchasing services.
The starting point for the assessment is the client contract and actual operations. Suppose a merchant contracts directly with a licensed institution, delivers assets to it, and that institution confirms the exchange rate and receipt of funds, while the company only provides order software. This is clearly different from the company quoting prices itself, collecting stablecoins, and then finding an upstream party to pay out fiat currency. In the latter arrangement, the upstream party may merely be your supplier; the client's claims against you do not disappear simply because a licensed party stands behind you.
Not touching funds is not the only criterion either.
Taking the UK payment regime as an example, the exclusion for technical services is subject to specific conditions, and payment initiation and account information services are not automatically excluded merely because no funds are held. Accordingly, where a company receives client instructions, determines the execution of payments, or arranges specific services, it must examine its actual activities rather than merely checking whether funds pass through its own bank account. This example illustrates only the method of assessment; the UK exclusion rules cannot be applied directly to other jurisdictions or to all crypto asset services.
Acting as an agent is permitted, but the conditions for agency must also be met.
UK FCA guidance makes clear that an agent of a payment institution must be registered by the principal institution and may provide only the payment services of the principal institution; it may not hold itself out as independently providing services in its own capacity. The EU's MiCA, in turn, requires entities providing crypto asset services to meet the corresponding admission requirements, and the related payment services carry separate qualification requirements. Therefore, "the upstream party holds a licence + we are partners" is not a licence-free formula that can be used across jurisdictions.
Align the contractual allocation of responsibilities with system permissions.
It is advisable to assign a responsible party, one by one, across the seven stages of account opening, client due diligence, quotation, collection and payment, refunds, complaints, and data retention, and to specify who has the final decision-making authority. Then check whether the product pages, customer service scripts, API permissions, and client statements are consistent. If the contract says the upstream party is responsible for payment, but the platform first promises receipt of funds and the upstream party has the right to reject orders at any time, there is a responsibility gap that should be closed before launch, rather than leaving clients to pursue the upstream party after the fact.
Recommended actions
- Collect the original text of the upstream licence and its restrictive conditions, and verify that the name of the cooperating legal entity matches the contracting entity.
- Prepare a responsibility and authority matrix covering the seven service stages, and check it against the actual front-end experience.
- Obtain advice on your own role in the target market; where agent registration is required, complete registration before providing the relevant services.
Information note: This article provides general information and does not replace legal advice based on specific facts.
References
- The Payment Services Regulations 2017，Schedule 1 — HM Treasury / legislation.gov.uk
- FCA Handbook PERG 15.4：Small payment institutions, agents and exempt bodies — UK Financial Conduct Authority (FCA)
- Article 59 of MiCA: Authorisation — European Parliament, Council of the EU / ESMA official rulebook
- Article 70 of MiCA: Safekeeping of clients’ crypto-assets and funds — European Parliament, Council of the EU / ESMA official rulebook
