How Broker Stablecoin Funding Is Structured

Trading clients increasingly want to fund accounts in stablecoins, and brokers increasingly want to let them. The obstacle is rarely demand. It is that receiving a virtual asset is a regulated activity a brokerage licence does not cover, and the structures built to solve that problem involve more than one licence, more than one party, and a set of obligations that do not all move together. This article explains how the structure works and what a broker needs to establish before relying on it.

It describes general market practice and regulatory requirements. It is not advice, and it does not describe any particular provider's arrangement.

Why are broker clients asking to fund in stablecoins?

A meaningful share of trading clients sit in markets where funding an account by card or bank transfer carries real friction. Cross-border card transactions attract higher decline rates and processing costs. Bank transfers depend on correspondent relationships and on business-hours processing windows at several institutions.

Stablecoin transfers operate outside the banking calendar. A client wanting to fund an account at the weekend, or after a correspondent bank's cut-off, has limited alternatives.

The demand is not usually about the asset. A client who sends a stablecoin to fund an account denominated in dollars or dirhams does not hold a crypto position once conversion completes. The stablecoin is a funding rail rather than an investment, and the motivation is access and reliability.

Why can't a broker simply accept crypto directly?

The intuitive answer — open a wallet, let clients send to it — creates a set of obligations a brokerage is not built to carry.

Receiving and holding a virtual asset is a regulated activity. In Bahrain it requires a licence from the Central Bank of Bahrain under Volume 6 of the CBB Rulebook. In the UAE, virtual asset activity in Dubai is licensed by VARA. A licence to operate as an FX or derivatives broker does not extend to virtual asset activities.

Custody. Holding a virtual asset for a client, even temporarily and even as a pass-through, constitutes custody — a separately regulated activity with its own capital, operational and reporting requirements.

Wallet screening. Whoever receives the transfer must screen the sending address against sanctions lists and risk models. That requires dedicated infrastructure or a third-party integration, and the obligation follows the receipt.

Sanctions and AML. A broker's existing programme would need extending to a new asset class, new counterparty types and new transaction typologies.

The Travel Rule. Where transfers occur between virtual asset service providers above applicable thresholds, originator and beneficiary information must be exchanged between institutions.

Regulatory scope. A firm that receives, holds, screens and converts virtual assets has changed what kind of entity it is, with consequences for capital, audit scope, client money rules and supervision.

A broker that accepts crypto directly has not added a funding method. It has changed what kind of business it is.

How is the structure usually built?

The structures that work keep the broker out of the asset entirely. The deposit leg is handled by a licensed provider, and the only thing the broker receives is fiat.

In outline:

1. The broker onboards the client under its own regulated framework
2. When the client chooses stablecoin funding, they are directed to a licensed provider's deposit flow
3. The provider issues a deposit address
4. The client sends stablecoins
5. The provider screens the sending address against sanctions lists and risk models
6. The provider applies transaction risk scoring
7. The provider converts the stablecoin to fiat
8. Fiat reaches the broker, which credits the client's trading account

The broker does not receive, hold, convert or exchange a virtual asset at any stage. What crosses its regulatory perimeter is fiat.

Division of responsibility as commonly structured. Specific arrangements vary by provider and jurisdiction.

The part that is easy to miss: conversion and payout are different activities

This is the point most explanations skip, and it matters more than the mechanics.

Converting a virtual asset to fiat and paying that fiat to a recipient are not the same regulated activity. They can require different authorisations, and in some jurisdictions they fall under different regulators entirely.

A provider may hold a licence covering the conversion - the trade from stablecoin into fiat - without holding the authorisation required to execute the fiat payout leg. Where that is the case, the payout is typically performed by a separately licensed entity, whether a partner institution or another entity within the same group.

Two consequences for a broker.

"We are licensed" is not a complete answer. The question is which activity the licence covers, and which party performs each leg. A provider should be able to say plainly: this entity holds this licence and performs this part; that leg is performed by that party under that authorisation.

The regimes differ by jurisdiction. Fiat payout may sit under a central bank's payment services framework, under a stored value or retail payment services regime, or outside those frameworks depending on how the transaction is characterised. A structure that is settled in one jurisdiction may be unresolved in another.

A broker evaluating a provider should ask for the licence position on both legs, and verify each on the relevant public register.

Licence categories and what each covers are set out in What Is a VARA Broker-Dealer Licence?

What does the broker still have to do?

The structure removes the crypto handling. It does not remove the broker's obligations, and a provider implying otherwise is overstating what it offers.

Client KYC and onboarding remain the broker's. Provider screening covers the deposit transaction and the sending wallet. It does not substitute for client onboarding.

Source-of-funds questions still reach the broker. If monitoring later raises a question about a client's funding, it is directed to the broker.

The funding method requires client disclosure. Clients need to understand that a third party is involved in the deposit leg and what they are agreeing to. Designing that disclosure is the broker's responsibility.

The broker's own regulator supervises the funding method. Introducing a new deposit mechanism may require notification or approval. That should be assessed with legal and compliance advisers before launch.

Reconciliation is the broker's operational problem. Each fiat receipt must reconcile against the corresponding client credits. The provider supplies data; the broker builds the process.

Ongoing monitoring continues. Provider screening covers the deposit event. The broker's transaction monitoring applies to the funded account and everything in it.

What about the Travel Rule?

FATF guidance requires that, where virtual asset transfers occur between virtual asset service providers above applicable thresholds, originator and beneficiary information is exchanged between the sending and receiving institutions. Thresholds, required data fields and implementation formats vary by jurisdiction, as does the allocation of responsibility between parties.

This article describes the requirement as published by FATF. It does not interpret how the rule applies in any jurisdiction or where the obligation falls in a given arrangement. Brokers should review FATF's guidance directly and confirm both the requirements and the allocation of responsibility with their own compliance advisers.

One practical distinction is worth understanding before designing a client-facing flow. A transfer from an address held at a regulated institution has an identifiable counterparty. A transfer from a self-hosted wallet does not, and is handled differently — typically through direct screening of the sending address, with manual review where required.

Those are two different client experiences with different expected timescales. A broker should establish what each looks like, how long review takes, and what happens to a deposit that does not pass, before the funding method goes live.

What a broker should establish before committing

Which licences, held by which entities, covering which legs? Conversion and payout may require different authorisations. Ask for the position on both, and verify each on the relevant public register. A licence reference without a matching register entry is not verification.

What is screened automatically, and what triggers manual review? The provider should be able to describe each process, the expected review window, and the escalation path when a deposit is held. "We do not accept self-hosted wallets" is a legitimate answer, and a constraint to know before building the client-facing flow.

What happens to a deposit that does not pass, and what does the client see? If manual review is the answer, the window matters. If rejection is the answer, the broker needs to know how funds are returned and what the client is told.

What settlement currencies, and what timing characteristics? Confirm the currency, the destination account type and the timing of each settlement — and whether the broker's own bank processes fiat receipts in real time or in batches, which is the last clock in the chain.

What reporting reconciles receipts against client deposits? The format must work with the broker's back-office systems. This is a design question to resolve before go-live.

What does the client see, and under whose name? Some implementations are white-labelled; in others the provider is visible. The disclosure a broker owes its clients depends partly on this, and legal should review the client-facing flow before launch.