Picture a games studio about to launch a rewards app. The brief says: add a wallet. Engineering picks a wallet as a service provider. Design adds three buttons, Receive, Swap and Cash Out. Marketing wants a launch banner for UK players. Someone says the wallet is non-custodial, so regulation is not a worry.

Then the questions start. The provider's recovery flow lets the studio's support team restore a user's access. The Swap button routes orders through a third-party aggregator and adds a fee. Cash Out hands users to an on-ramp partner who asks who handles complaints. Several of these facts change the legal analysis.

"Wallet" describes a screen. It does not say who controls the keys, who can move or block assets, which services sit behind each button, or where the users live. Each of those facts feeds a different legal question: regulatory classification, financial promotions, AML, privacy, consumer disclosure, vendor contracts and app-store approval.

The short answer is this. A simple connection to a user's own external wallet usually carries the lightest legal load. Custody, swaps, bridges, staking and fiat on ramps each add questions, and some add obligations. The labels "custodial" and "non-custodial" are a starting point, never the conclusion. The twelve questions below follow the order a product counsel would ask them, and end with a checklist for launch week.

1. What kind of wallet are you actually adding?

Teams use "wallet" for four different architectures.

An external connection lets users link a wallet they already own, through a browser extension or a protocol such as WalletConnect. Your app sees a public address and asks the user to sign requests. Keys never reach you.

An embedded wallet is created inside your app, often tied to an email or social login. The user may never see a seed phrase. Key material can sit on the device, on a server, or in pieces across several parties.

Wallet-as-a-service is provider infrastructure that powers embedded wallets. Whether it is custodial depends on how the provider handles keys, not on its marketing page.

A custodial wallet is one in which a provider or intermediary controls the private keys or otherwise has the practical ability to safeguard and authorise transfers of users’ crypto-assets. The provider may maintain internal balances or segregated on-chain holdings, depending on its architecture.

Labels do not settle the analysis. Ask engineering for an architecture diagram and a plain list of who can do what. Counsel can work from that.

2. Who holds the private keys, and who can recover them?

Modern wallets break the old either/or. Many MPC-based wallets use threshold cryptography, in which signing authority is distributed across multiple parties or devices. A transaction can be authorised when the required threshold participates, without reconstructing the complete private key in one location. The precise architecture and recovery arrangements vary between providers. One example is a three-share setup: one share on the user’s device, one with the provider and one with a recovery factor, such as an encrypted cloud backup.

Smart-contract accounts built on account-abstraction standards add rules, spending limits, session keys and guardian-based recovery.

None of this is custodial or non-custodial by itself. The legal question is who can, in practice, cause a transfer. Ask:

1. Can the user alone authorise a transaction?
2. Can your team or the provider refuse to co-sign, or sign without the user?
3. If a user loses their phone, who restores access, and on what proof?
4. Could an insider, a court order or a compromised admin account force a signature?

Regulators ask similar questions. MiCA defines custody and administration of crypto-assets for clients by reference to safekeeping or controlling the assets or the means of access, including private keys (Article 3(1)(17)). The FCA's final perimeter guidance, PS26/18, treats safeguarding as a question of control over the ability to transfer. Contract wording does not change that.

3. Can your business initiate, block or reverse transactions?

Blockchain transactions are generally difficult to reverse once they reach finality, but confirmation and finality are not identical. The degree of finality depends on the network’s consensus mechanism, and some tokens or smart contracts may permit separate administrative controls, such as freezing assets. A token freeze restricts what can be done with a token. It does not reverse the underlying chain transaction. None of this means your business is powerless before or around that moment. Map every power you have:

1. signing or co-signing
2. allow lists and block lists
3. freezes and withdrawal delays
4. spending limits and policy rules
5. recovery and key rotation
6. smart-account permissions, including who can add or remove signers
7. emergency pause

One caution. Some stablecoin issuers can blacklist addresses at token level. That is the issuer's power, not yours, and your terms should not suggest otherwise.

Small conveniences can change the picture. In a Q&A answer dated 9 July 2025, ESMA said that pre-funding client orders with clients' crypto-assets counts as sub-custody under MiCA.

These facts feed three analyses: regulatory classification, contract terms and user disclosures. If your terms say you cannot access user funds, but support can restore an account, you have a mismatch that a regulator or a claimant will find.

4. What can users do from inside the wallet?

List each function separately. Every added function can change the regulatory perimeter.

What must users be told

Treat each added function as its own launch decision. A review sized for version one will not cover a Swap button added in version three.

5. Who provides the crypto and payment infrastructure?

A wallet product rarely runs on one vendor. Behind it you may have a wallet infrastructure provider, an exchange or liquidity provider, an on-ramp, a payment processor, a bridge and a blockchain node or RPC service. Your user sees one app. Your contracts have to cover all of them.

A provider's compliance does not become yours automatically, and yours does not become theirs. Before signing, check:

1. Status. What licences or registrations does the provider hold, for which activity and in which countries?
2. Role. Who is the merchant of record and the contracting counterparty for each service?
3. Compliance split. Who runs KYC, sanctions screening and monitoring, and who answers to the regulator?
4. Data. Who is controller and who is processor, and do the data terms say so?
5. Resilience. What are the service levels, the incident notification times and the exit plan if the provider fails?
6. Liability. What do the indemnity and liability caps cover, and do they match the real exposure?

6. Do you need KYC, AML and sanctions controls?

It depends on the regulated activity, the entity performing it and the jurisdiction. A blanket rule that every wallet needs KYC is wrong. So is the opposite assumption that a non-custodial label removes AML questions.

A plain connection to a user's own wallet, with no regulated service attached, may carry no crypto-specific KYC duty for you. Add custody, exchange, transfer or fiat conversion, and obligations arise for whoever performs the regulated service. Often that is your partner. Check by contract, not by assumption.

The usual toolkit includes customer due diligence, sanctions screening of users and addresses, transaction monitoring with blockchain analytics, and geographic controls. Be realistic about limits. Address screening is probabilistic, and IP-based geoblocking can be bypassed with a VPN. Layered controls work better than one gate.

In the EU, for example, Regulation (EU) 2023/1113 applies to crypto-asset transfers handled by a crypto-asset service provider (CASP). For a transfer to or from a self-hosted address, the CASP must collect the originator and beneficiary information from its own client and make sure the transfer can be individually identified. For transfers above EUR 1,000, it must also take adequate measures to assess whether that address is owned or controlled by its client (Articles 14(5) and 16(2)). Your users may meet these checks at your partner’s door. Use the regulator and statute of each target market for any specific duty.

7. What do UK rules require today, and what changes on 25 October 2027?

Keep two regimes apart.

Today: financial promotions. Since 8 October 2023, promotions of qualifying cryptoassets to UK consumers fall under the FCA's financial-promotion framework (PS23/6). A promotion generally has to come from an FCA authorised firm, be approved by one, or rely on an exemption or the registration route. The rules include a prescribed risk warning and, for direct offer promotions to first time investors, a 24 hour cooling-off period. An in-app banner saying "Buy crypto in two taps" can be a promotion. Whether yours is depends on the content and the asset.

Coming: the FSMA cryptoasset regime. Treasury made the Financial Services and Markets Act 2000 (Cryptoassets) Regulations 2026 in February 2026. The FCA published its final policy statements and rules on 30 June 2026 and its perimeter guidance, PS26/18, on 16 September 2026. On the FCA’s timeline, the application period opened on 30 September 2026 and ends on 28 February 2027, which is the deadline for firms that want transitional protection. The FCA describes 25 October 2027 as the date the regime is expected to come into force. Do not describe it as already in force.

The activities most relevant to wallets are safeguarding, arranging safeguarding, dealing, arranging deals and arranging staking. PS26/18 says that developing software is not itself a regulated activity. The consultation draft, which the final guidance broadly follows, said that giving users a way to place orders may amount to arranging deals. So a wallet that is merely software sits differently from one that routes orders. The FCA has said it will consult in the fourth quarter of 2026 on targeted changes to this guidance, and HM Treasury has laid draft amending regulations, so check the current text before you rely on it.

Promotions rules and authorisation rules are separate. You can need one without the other.

8. How does MiCA apply, and what about the US, UAE and other markets?

EU. Start with the facts, not the label. Does the functionality amount to a crypto-asset service under MiCA, such as custody, transfer, exchange or order execution? A wallet that only connects to the user's own self-hosted wallet, with no access to keys or assets, may sit differently from one that controls them. Do not assume either way.

Timing matters. MiCA let providers that were lawfully operating under national law before 30 December 2024 continue for a limited time, until 1 July 2026 at the latest or until their authorisation was granted or refused. Under Article 143(3), Member States could shorten that period or decide not to apply it, so the window was not identical across the EU. ESMA publishes a list of the national periods. With that date now passed, providing crypto-asset services to EU clients without CASP authorisation is a breach.

US, UAE and elsewhere. Each market needs its own perimeter analysis against local licensing, securities, payments and AML rules. Treat statements from foreign-law summaries, including this one, as prompts for questions to local counsel, not conclusions.

9. What personal data flows behind a wallet, and does GDPR apply?

Map the data before you write the privacy notice. A wallet product usually touches account details, wallet addresses, transaction history, device data, analytics events, KYC records and third-party SDK data. Node and RPC providers can also see IP addresses alongside the addresses and balances a user queries.

Whether a wallet address is personal data depends on whether a person can be identified in context. On 7 July 2026 the EDPB adopted the final version of Guidelines 02/2025 on processing of personal data through blockchain technologies. As summarised by the Board and commentators, the final text treats on chain identifiers, such as addresses and transaction identifiers, as capable of being personal data. It also discourages putting personal data on-chain, including in hashed or encrypted form, and expects a prior assessment of whether a blockchain is necessary and a DPIA where the processing warrants one. For GDPR application read Have EU Customers? Why GDPR Applies to Your Business and How to Comply Without Overcomplicating It (2026 Guide)

Practical consequences:

1. Roles. Decide who is controller and who is processor for each flow. Wallet providers often act as controllers for some of their data.
2. Notice. Explain that on-chain records are public and hard to erase.
3. Design. Never write names, emails or other direct identifiers into on-chain metadata.
4. Retention and transfers. Set retention rules for off-chain data and check cross-border transfer mechanisms.

10) What must users be told about fees, errors and irreversible transactions?

Technical finality and legal duty are different things. A transfer may be effectively irreversible on-chain while you still owe users clear information and a working complaints route.

Tell users, in plain language:

1. which fees apply, including network fees, your fee and any spread in the exchange rate
2. how congestion can delay or fail a transaction
3. what happens if they send to a wrong address or the wrong network
4. which assets the app does not support, and what happens to unsupported tokens
5. how scams work, including fake support and look-alike addresses
6. what recovery is possible and what is not
7. where to complain

Be careful with disclaimers. Consumer laws limit exclusion of liability, and a disclaimer cannot waive rights that statute makes non-excludable. It also cannot rescue misleading screens. Fix the interface as well as the terms. Confirmation screens that show the network, fee previews and warnings before first transfers are product choices that support your position. They are recommendations, not legal mandates.

11) What happens when keys are lost or an incident hits?

Typical events include key compromise, phishing, malicious token approvals, smart-contract exploits, provider outages, chain or bridge incidents and email-based account takeover.

The legal question follows the technical one: what can your company actually do during an incident? Can you pause signing, revoke session keys, rotate key shares, disable a feature, or ask a stablecoin issuer to freeze tokens? What you can do should shape what you promise. "Your funds are always safe" and "we can recover any account" are claims your architecture may not support.

Common drafting mistake. Terms that say "we cannot access or recover your assets" while support restores accounts by email. Either the terms or the process has to change.

Treat this as a joint exercise with your security team, not only a terms-of-service issue. Agree the playbook before launch: who decides to pause the product, who speaks to the provider, who contacts regulators and users. Where GDPR applies, a personal data breach can start a 72-hour notification clock for the supervisory authority. A provider contract that promises notice within a "reasonable time" may leave you short of that.

12) Who owns the code, and will the app stores approve the wallet?

SDKs, open source and trademarks. Wallet SDKs arrive with licences. Permissive licences such as MIT mainly ask for attribution. Copyleft licences, including AGPL, can impose source-sharing duties that reach network use. SDK terms may also limit use cases or territories, require security updates or restrict use of the provider's name. Check who owns your customisations and what happens to embedded components if the provider ends the licence.

Apple and Google. Platform rules are contractual. They sit alongside the law and can change on their own timetable. Meeting the law does not guarantee approval.

1. Apple. The App Review Guidelines last updated 8 June 2026, allow wallet apps from developers enrolled as organisations (3.1.5(i)). Exchange transactions are allowed only where the app holds appropriate licensing (3.1.5(iii)). Apps may not mine on device, and may not reward users with currency for tasks such as downloading other apps (3.1.5(ii) and (v)). Apps cannot unlock features using cryptocurrencies or wallets, and NFT rules sit in 3.1.1.
2. Google Play. Its policy on cryptocurrency exchanges and software wallets took effect on 28 January 2026. It excludes non-custodial wallets from that policy. For exchanges and software wallets aimed at listed countries, developers must supply licence or registration details and complete a financial-features declaration. The country list changes, so check it on the day you submit.

The 12 question pre-launch wallet checklist

1. Custody and key control. Who can authorise a transfer, alone or together?
2.  Recovery. Who can restore access, and with what proof?
3. Transaction powers. Can you sign, block, freeze, limit or pause?
4. Supported functions. Send, buy, swap, bridge, stake, lend, NFTs, ramps: which, and in which release?
5. Asset types. Which tokens, stablecoins and NFTs, and how are unsupported ones handled?
6. Third parties. Who provides infrastructure, liquidity, ramps and nodes, and on what role?
7. Target countries. Which markets, and what perimeter analysis for each?
8. KYC, AML and sanctions. Who runs them, and how is it evidenced?
9. Privacy and data. Are flows mapped, roles allocated, notices and any DPIA done?
10. Consumer disclosures. Fees, finality, errors, scams and complaints explained plainly?
11. Security and incident response. Does the playbook match your real technical powers?
12. Contracts, licences and approvals. Vendor terms, SDK licences, store policies and marketing sign-off?

Related Articles

1)   Accepting Crypto Payments from Foreign Clients: What FEMA Allows

2)   RECOGNITION OF CRYPTOCURRENCY AS PROPERTY UNDER INDIAN LAW: IMPLICATIONS AND CHALLENGES

FAQs

1)   Does a non-custodial wallet need regulatory approval?

There is no universal yes or no. The answer depends on the full functionality, your role, the jurisdiction and the services attached, such as swaps, staking or order routing. A non-custodial design can reduce some obligations. It does not make a product unregulated by default.

2)   Do users need KYC to connect a wallet?

Not automatically in every context. A simple connection to a user's own wallet differs from a regulated service such as custody, exchange or fiat conversion. KYC duties follow the activity and the entity performing it, so check your own role and your partners' roles.

3)   What is the legal difference between custodial and non-custodial wallets?

It lies in who controls the keys and the ability to move assets. Control can affect licensing, safeguarding duties and user disclosures. Labels alone are not determinative. Regulators look at actual control, including shared-key and recovery arrangements.

4)   Can an app let users swap or bridge crypto without extra legal analysis?

No. Swaps, bridges and third-party execution raise questions about the provider's role, the regulatory perimeter, sanctions, security and fee disclosure.

5)   Are wallet addresses personal data under GDPR?

Sometimes. Identifiability and context decide. The EDPB’s final Guidelines 02/2025, adopted on 7 July 2026, are the main reference. Do not treat addresses as automatically anonymous.

6)   What contracts do you need with a wallet infrastructure provider?

Cover service scope, allocation of compliance duties, data protection terms, security standards, incident notification, service levels, IP and licensing, liability and indemnity, termination, and migration or continuity if the provider fails.

When to get legal review

Legal review is most useful before architecture is fixed, and again before each new function ships. If you are choosing a wallet model, signing a provider contract or planning a UK or EU launch, an early review can avoid redesign later. The right analysis depends on your actual architecture, functionality, users and jurisdictions, and regulated activities may need specialist local counsel.

Author: Gaurav Saxena is the Founding Partner of SolvLegal Law Offices LLP, with over 14 years of experience advising startups, technology companies, and global businesses on commercial, technology, intellectual property, and regulatory matters. He focuses on delivering practical, business-oriented legal solutions for companies operating in fast-evolving digital and cross-border environments.

Disclaimer: This article is intended solely for general informational and educational purposes. It does not constitute legal, tax or financial advice, advertising, or solicitation. The legal position on crypto wallet functionality depends on the product’s architecture, the services offered, the entity involved, the users and the jurisdictions concerned. Regulatory timelines, exemptions, guidance and app-store policies discussed here, including the UK cryptoasset regime due to take effect on 25 October 2027, may change. The position should be verified against current primary sources at the time of any product launch. This article reflects the position as at 10 October 2026. Regulated activities in the UK, EU, US, UAE or other markets may require advice from qualified local counsel. Independent professional advice should be obtained before launching a wallet feature or relying on this article.