Annexure 14 · Founder resources · Web3 & digital assets

The self-custody compliance controls checklist

Which controls keep a wallet provider outside custody licensing depends on one architectural fact in four different legal tests: whether anyone other than the client can move funds or hold a means of access. Controls 1 to 5 below are the ones that decide it, and controls 6 to 12 are the non-custodial wallet AML obligations that follow under FinCEN, MiCA, VARA and FIU-IND if they do not. Twelve controls, in the order a wallet or self-custody platform should build them, each tied to the rule that asks for it in the US, the EU, Dubai and India, and crosswalked to SOC 2. Read the explainer first: Self-custody meets institutional control, our joint article with Reah on where the legal line on custody licensing actually sits.

Or get it by email
Verified as of 12 September 2026. This checklist reflects FinCEN guidance FIN-2019-G001, MiCA (Regulation (EU) 2023/1114), DORA (Regulation (EU) 2022/2554), the recast Transfer of Funds Regulation (EU) 2023/1113, the VARA Custody Services, Technology and Information, and Compliance and Risk Management Rulebooks in the version dated 19 May 2025, and FIU-IND’s AML & CFT Guidelines for VDA reporting entities dated 8 January 2026, as they stood at that date. The US row is federal only. On 15 September 2026 the Senate vote to invoke cloture on the motion to proceed to H.R.3633, the Digital Asset Market Clarity Act, failed, so nothing in that bill is enacted and FinCEN guidance FIN-2019-G001 remains the operative federal money-transmission position. Published 18 September 2026. Thresholds and clocks are the regulators’ to change; confirm anything you rely on against the current text, or ask us to.

Which controls keep a wallet provider outside custody licensing

“Non-custodial” is not a self-certifying label anywhere: the US asks who can move funds unilaterally, the EU asks who controls the means of access, and India and the UAE ask what function the platform performs in substance. And SOC 2 is an attestation, not a licence: a CPA firm’s report on your controls, which no regulator issues and which none of the four regimes on this page treats as a substitute for authorisation or registration. Work through the twelve in order. Controls 1 to 4 are key architecture; control 5 is the perimeter test; 6 to 8 are what follows if you are inside it, and what serious clients ask for even if you are not; 9 to 12 are the operating programme. Classification is fact-specific, and this page does not assess any platform’s architecture.

Generate keys so that no single person or location can sign

The first control is architectural, and it is the one every regulator that licenses custody has written down. A key that can move funds on its own is a single point of failure, whatever the marketing says.

  • Generate keys in a ceremony designed so that a key stored online, or in one physical location, is not on its own capable of conducting a transaction unless controls make physical access insufficient. That is VARA’s Custody Services Rulebook (Rule III.C.2) and its Technology and Information Rulebook (Rule I.D.2), which requires no single point of failure in access to, or knowledge of, virtual assets.
  • Split signing authority across people and devices. VARA expects multi-signature or multi-key approaches to be considered, may require them, and requires collusion risk among signatories to be mitigated. For an EU CASP, DORA Article 9(4)(d) requires policies for strong authentication and protection of cryptographic keys.
  • Document the architecture as you build it. FinCEN’s 2019 guidance prescribes no key design; it asks who has total independent control over the value. The design record is the evidence for control 5.

Back up seeds in split form, in a separate location, with equal encryption

Backups are where key hygiene fails quietly. A single, complete seed phrase in a drawer undoes every signing control above it.

  • Store backups in a location separate from the live keys, with encryption equal to the primary storage. VARA’s Custody Rulebook (Rule III.C.2) requires mnemonic seed backups to be split into at least two parts; the Technology Rulebook (Rule I.D.2) repeats the separate-storage requirement.
  • Write the restoration procedure and test it. DORA Article 12(1) requires documented backup and restoration procedures for financial entities in scope, and Article 11(1) an ICT business continuity policy.
  • In India, the Cyber Security Audit Certificate that FIU-IND requires at registration (Guidelines of 8 January 2026, para 2.4(j)) must cover backup and recovery and cryptographic controls, issued by a CERT-In empanelled auditor. Build the backup evidence before the audit, not for it.

Run access management as a signatory register with a leaver process

Who can touch a key today is a list; who could touch one last quarter is an audit question. Both need answers.

  • Grant system and data access only to people with a demonstrable business need and keep an access log (VARA Technology Rulebook, Rule I.D.4). For an authorised CASP, DORA Article 9(4)(c) limits access to legitimate and approved functions and Article 9(4)(e) requires documented ICT change management.
  • Keep an audit log of every change of key access, and when anyone holding a key, including one multi-signature key, leaves, reassess whether to re-key. VARA requires quarterly internal audits of access removal (Rule I.D.2), and requires client agreements to cover revocation of key signatories’ access (Custody Rulebook, Rule III.D.1).
  • In India, transaction-monitoring systems must run on role-based access control with reliable backup and recovery (FIU-IND Guidelines, para 5.2.3). The same register serves both regimes.

Authorise transactions with step-up controls on limits and address changes

A verified instruction is the unit of custody. The controls around it decide whether the platform, or the client, is the one deciding.

  • Apply multi-factor authentication, or a better standard, to transactions that exceed limits the client has set or are initiated after a change of wallet address, with client authentication and session controls. That is the minimum content of a VARA Cybersecurity Policy (Technology Rulebook, Rule I.B); DORA Article 9(4)(d) asks for strong authentication mechanisms.
  • Act only on verified client instructions. VARA’s Custody Rulebook (Part III.A) allows custody only on verified instructions, and client assets are not depository liabilities of the VASP.
  • Screen before you sign. FIU-IND requires sanctions screening when any VDA transaction is initiated, with safeguards such as holding a wallet until screening clears (para 5.4); VARA requires automated, real-time screening with immediate freezing on a match (CRM Rulebook, Rule III.H).

Keep the client’s key with the client, and test who can move funds without them

This is the perimeter control. Every regulator on this page asks a version of the same question; none of them accepts the label as the answer.

  • United States: FinCEN’s 2019 guidance turns on four criteria: who owns the value, where it is stored, whether the owner interacts with the payment system directly, and whether the intermediary has total independent control. A provider that only creates unhosted wallets requiring a second authorisation key alongside the owner’s private key is not a money transmitter; it becomes one if it also hosts the wallet, books the value as an entry in its own accounts, stands between the owner and the payment system, or keeps total independent control, “regardless of the label the person applies to itself”.
  • European Union: MiCA Article 3(1)(17) defines custody as safekeeping or controlling crypto-assets or the means of access to them, including private keys. Recital 83 keeps hardware and software providers of non-custodial wallets outside the Regulation, and in the same recital notes that a custody agreement may cover holding the means of access while the client keeps control. Clearing FinCEN’s narrower unilateral-control test does not clear MiCA’s broader means-of-access test; they are two different legal tests.
  • UAE and India: VARA treats client assets as held or controlled by a VASP where the private keys or seed phrase are held or controlled by the VASP (CRM Rulebook, Rule V.A.2(d)), and a custody VASP must maintain control of each asset at all times (Custody Rulebook, Rule III.B.4). FIU-IND’s obligations are activity-based, cover safekeeping or administration of VDAs or instruments enabling control over them, apply irrespective of physical presence in India, and are not avoided by automating the function in a smart contract: the controlling parties are the reporting entity. Write the answer down per market. Classification is fact-specific.

Segregate client assets and never rehypothecate

If control 5 lands you inside custody anywhere, this is the first obligation that follows. If it lands you outside, it is still what serious clients will ask to see.

  • MiCA Article 75(7): client crypto-assets segregated from the CASP’s own on the distributed ledger, the means of access clearly identified, and legally segregated so creditors have no recourse in insolvency. Article 70(1) requires arrangements that safeguard clients’ ownership rights and prevent use of client assets for the CASP’s own account.
  • VARA: each client’s assets in separate wallets labelled Client VA Wallet, held one-to-one, not rehypothecated absent explicit consent and licence, and not part of the VASP’s estate in insolvency (CRM Rulebook, Parts V.B and V.D). Custody must sit in its own legal entity, separate from any group member running other VA activities, with a limited exception for VA Transfer and Settlement Services (Custody Rulebook, Rules III.B.5 to 6).
  • Sub-custody has the same shape. MiCA Article 75(9) permits sub-custodians only if they are CASPs authorised under Article 59; ESMA’s statement of 23 June 2026 reminds CASPs they may not delegate custody to unauthorised entities.

Keep a register of positions, reconcile daily, retain for the longest clock

Regulators read the register before they read the code. Build one that would satisfy the strictest regime you might operate in.

  • A register of positions opened in the name of each client, with movements recorded as soon as possible (MiCA Article 75(2)); a register and reconciliation record of each client’s positions (VARA Custody Rulebook, Rule III.D.2.b). VARA requires reconciliation daily, with unrectified material discrepancies notified to VARA (CRM Rulebook, Part V.D).
  • Statements of position: at least once every three months and on request under MiCA (Article 75(5)); monthly under VARA (Custody Rulebook, Rule III.D.4).
  • Retention: MiCA records for five years, extendable to seven at the competent authority’s request (Article 68(9)); VARA books, AML records and the custody audit trail, including date, time, type, signatories and assets, for no less than eight years; FIU-IND identity records for at least five years after the relationship ends and transaction records for five years from the transaction, with tamper-proof audit trails including authentication logs (para 6.2). Build for eight.

Put the security model in the client agreement

The agreement is where the control architecture becomes a promise the client can read, and where the regulator checks that the promise matches the build.

  • MiCA Article 75(1) requires a written custody agreement covering, among other items, the custody policy, the client’s authentication system and a description of the security systems used; Article 75(3) requires a custody policy that minimises the risk of loss from fraud, cyber threats or negligence, with a summary available to clients on request.
  • VARA’s Custody Rulebook (Rule III.D.1) requires client agreements to cover multi-signature or multi-key safeguards, access management and revocation of key signatories’ access; Rule III.C.3 requires policies for lost or compromised keys covering recovery, client communication, law-enforcement cooperation and wind-down; Rule III.D.2.a frames custody as a transfer of control, never of legal interest.
  • Tell clients how to protect their own keys and seed phrases (VARA Technology Rulebook, Rule I.D.3), publish a complaints procedure that is free to use (MiCA Article 71), and know the liability you are taking on: a custody CASP is liable for losses from incidents attributable to it, capped at market value at the time of loss, but not for problems inherent in a ledger it does not control (Article 75(8)).

Test independently, before launch and at least annually

Every regime on this page wants a third party to have tried to break the system, and to try again each year.

  • VARA Technology Rulebook, Rule I.E.1: independent third-party vulnerability assessment and penetration testing, including smart contract audits where relevant, at least annually and before any new system, application or product; Rule I.E.4 regular independent audits of controls; Rule I.E.5 threat-led penetration testing where VARA requires it. Rule I.B adds code and smart contract validation to the Cybersecurity Policy.
  • For an authorised CASP, DORA Articles 24 and 25 require a digital operational resilience testing programme for entities other than microenterprises, including vulnerability assessments, scans, source code reviews and scenario-based tests; Article 26(1) threat-led penetration testing at least every three years for entities the competent authority identifies.
  • India: the CERT-In empanelled audit certificate at FIU-IND registration covers wallet security, cryptographic controls, third-party, cloud, custodian and API risks (para 2.4(j)); the ML/TF/PF risk assessment must be refreshed at intervals not exceeding one year and before new technologies or products launch (para 3.6.1).

Run an incident process with the reporting clocks pre-written

The clocks are short and they start at detection, not at diagnosis. Write the notification templates before you need them.

  • VARA: material cybersecurity events reported within 72 hours of detection (Technology Rulebook, Rule I.K.1); a BCDR Plan tested and updated annually that addresses key storage and authorisation layers (Rules I.H.1 to 2); a CISO separate from the Compliance Officer (Rule I.I.1); lost or compromised key policies with client communication and law-enforcement cooperation (Custody Rulebook, Rule III.C.3).
  • DORA, for an authorised CASP: an ICT-related incident management process (Article 17(1)) and reporting of major ICT-related incidents to the competent authority (Article 19(1)); mechanisms to promptly detect anomalous activities and single points of failure (Article 10(1)).
  • India: the CERT-In audit certificate must cover incident detection with CERT-In reporting readiness under the CERT-In Directions of 28 April 2022 issued under section 70B(6) of the IT Act 2000 (FIU-IND Guidelines, para 2.4(j)).

Name the officers and audit the AML programme every year

A tool you bought is not a policy. Each regime wants a named human, resident where the regulator is, who owns the programme and answers for it.

  • Dubai: a Compliance Officer with at least five years’ relevant experience, VARA fit-and-proper approval, UAE residence or passport, full-time employment and direct reporting to the Board (CRM Rulebook, Rule I.C.1); an MLRO with at least two years’ AML/CFT experience (Rule III.A.1); the same person may hold both roles where no conflict arises (Rule I.C.4). For VARA licence figures, see VARA licence cost, capital and timeline.
  • India: a Designated Director and a Principal Officer who are separate individuals; the PO management-level, full-time, exclusive to the entity, based in India, with at least three years’ relevant experience, reporting to the Board at least annually (paras 3.1 to 3.3); an independent annual audit of AML/CFT/CPF controls reported to the Board (para 3.6.3); registration on the FINGate portal with an in-person meeting and live demonstration of KYC, monitoring, blockchain analytics, travel-rule and screening tools (paras 2.2, 2.5). Non-registration is a PMLA violation (para 2.1). Sequence it with the FIU-IND registration checklist.
  • EU and US: a CASP must have the DORA systems and the AML risk-assessment arrangements under national law transposing Directive (EU) 2015/849 (MiCA Article 68(8)); under the Bank Secrecy Act, MSB status follows activities, not the label, and the programme follows the status. Whichever market: a written policy with a named owner, KYC that runs, and a suspicious-transaction process that actually files.

Handle self-hosted transfers and screening as a written rule, not a judgment call

The self-hosted address is where regulators watch licensed entities most closely. If your clients’ wallets are the self-hosted side of someone else’s transfer, expect these questions from their compliance teams.

  • European Union: a transfer is only inside the travel-rule regime where a CASP acts on at least one side (Regulation (EU) 2023/1113, Article 3(10)); a self-hosted address is a distributed ledger address not linked to a CASP or to a non-EU entity providing similar services (Article 3(20)). On any transfer to or from a self-hosted address the CASP must obtain and hold the originator and beneficiary information, with no de minimis threshold; where the amount exceeds EUR 1,000 it must in addition take adequate measures to assess whether the address is owned or controlled by its own customer (Articles 14(5) and 16(2)); recital 45 expects enhanced due diligence where data is inaccurate or patterns unusual.
  • Dubai: before any transfer above AED 3,500 equivalent, originator and beneficiary information obtained and held (CRM Rulebook, Rules III.G.2 to 3); the risks of non-obliged entities, meaning unhosted wallets, considered (Rule III.G.7.b); travel-rule compliance demonstrated at licensing with a plan for the sunrise issue (Rule III.G.8); screening records and freezing actions retained for at least eight years and FIU or VARA information requests answered within 48 hours (Rules III.F, III.H).
  • India and US: India’s travel rule applies to transfers between wallets hosted by reporting entities, requires PAN, identity document number, name, wallet address, verified address and date of birth for the originator, and does not permit post-facto submission (para 5.3); for hosted-to-unhosted transfers the onus sits with the entity hosting the wallet, which must collect data, apply enhanced CDD and may impose limits or prohibitions (para 7.2); anonymity-enhancing tokens, tumblers and mixers may not be facilitated (paras 7.4 to 7.5); STRs are filed irrespective of amount and a monthly report goes to FIU-IND (paras 5.5 to 5.7). In the US, a hosted wallet provider must comply with the Funds Travel Rule, 31 CFR 1010.410(f), based on its position in the transmission chain.

Schedule A: control by regime

The table reads across: what each regulator asks of the control group on the left, and which SOC 2 Trust Services category a CPA’s examination would most likely test it under, on our reading of the five categories. The SOC 2 column describes an attestation, not a legal requirement; the four regulator columns are the law. DORA applies to the financial entities listed in its Article 2(1), which include CASPs authorised under MiCA; a provider that is not an authorised CASP is not a DORA financial entity, and the DORA entries read as the standard it would have to meet on authorisation. Sources are the primary texts named in the notice above; VARA references are to the rulebooks in the version dated 19 May 2025, FIU-IND references to the guidelines of 8 January 2026, all as at 12 September 2026.

Schedule A · Compliance controls for non-custodial wallet infrastructure against FinCEN, MiCA and DORA, VARA, FIU-IND and SOC 2, as at 12 September 2026
Control groupFinCEN (US, federal)MiCA and DORA (EU)VARA (Dubai)FIU-IND (India)SOC 2 criteria (Trust Services category)
Perimeter test (control 5) FIN-2019-G001 s.4.2: who owns the value, where it is stored, direct interaction with the payment system, total independent control; label irrelevant (s.4.2.2). Remains the operative federal position; H.R.3633 s.109 not enacted after the failed Senate cloture vote of 15 September 2026 Art 3(1)(17) safekeeping or controlling crypto-assets or the means of access; recital 83 non-custodial wallet software out of scope; Art 59(1) authorisation for services in scope CRM Rulebook V.A.2(d): held or controlled where private keys or seed phrase are held or controlled by the VASP; Custody Rulebook III.B.4 control at all times Paras 1.2.2(iv), 1.4, 7.1.2: safekeeping or administration or instruments enabling control, activity-based, presence irrelevant, smart contracts do not relieve controlling parties None. SOC 2 does not classify; it attests to controls once the classification is made
Key generation and backup (controls 1 to 2) No prescriptive rule; the architecture is evidence under the control test DORA Art 9(4)(d) protection of cryptographic keys; Art 12(1) backup and restoration; Art 11(1) continuity policy Custody III.C.2 and Technology I.D.2: no single point of failure, keys online or in one location cannot transact, split seed backups, separate storage, multi-signature considered Para 2.4(j): CERT-In audit certificate covering wallet security, cryptographic controls, backup and recovery Security; availability
Access and authorisation (controls 3 to 4) Independent control facts (s.4.2.2) decide status; no separate access rule DORA Art 9(4)(c) approved functions only, 9(4)(d) strong authentication, 9(4)(e) change management Technology I.B MFA on limit breaches and address changes; I.D.2 key-access audit log, re-keying on leavers, quarterly access audits; I.D.4 business-need access Para 5.2.3 role-based access; para 5.4 screening at transaction initiation and wallet hold Security; processing integrity
Segregation and register (controls 6 to 7) Hosted wallet providers are account-based money transmitters (s.4.2.1); no segregation rule in the guidance Art 70(1) ownership rights; Art 75(2) register; Art 75(7) segregation, no creditor recourse; Art 75(5) statement every three months; Art 68(9) records five years, up to seven CRM V.B and V.D: Client VA Wallet, one-to-one, no rehypothecation, daily reconciliation; Custody III.D.2.b register, III.D.4 monthly statements, III.D.5 eight-year audit trail; III.B.5 separate custody entity Para 6.2: identity records five years after the relationship, transaction records five years, tamper-proof audit trails Processing integrity; security
Client agreement (control 8) Contractual limits do not defeat total independent control (s.4.2.1) Art 75(1) custody agreement, 75(3) custody policy, 75(8) liability, Art 71 complaints Custody III.D.1 multi-key safeguards and revocation, III.C.3 lost-key policies, III.D.2.a control not legal interest; Technology I.D.3 client key guidance No custody-agreement requirement in the sourced paragraphs; KYC updation at least every six months for high-risk clients and at least annually otherwise (para 4.5.2) Confidentiality; security
Testing and incidents (controls 9 to 10) No equivalent requirement in FIN-2019-G001 DORA Arts 24 to 26 testing programme, TLPT at least every three years where identified; Art 17(1) incident process; Art 19(1) major incident reporting Technology I.E.1 annual independent pen test and before new products; I.K.1 report within 72 hours of detection; I.H.1 to 2 BCDR annually covering key storage; I.I.1 CISO separate from CO Para 2.4(j) CERT-In audit and reporting readiness under the 28 April 2022 Directions; para 3.6.1 risk assessment at least yearly and before new products Security; availability
AML programme and officers (control 11) MSB status follows activities (s.2); BSA programme follows status Art 68(8): DORA systems plus AML risk assessment under national law transposing Directive (EU) 2015/849 CRM I.C.1 Compliance Officer, five years, UAE resident, full-time; III.A.1 MLRO, two years; I.G.1 annual audit proving existence and ownership of assets Paras 3.1 to 3.3 Designated Director and Principal Officer, separate, PO in India with three years; para 3.6.3 independent annual audit; paras 2.1 to 2.5 registration and live demonstration Not a Trust Services category; SOC 2 does not test AML compliance
Self-hosted transfers and screening (control 12) Funds Travel Rule, 31 CFR 1010.410(f), for hosted wallet providers by position in the chain (s.4.2.1) TFR Art 3(10) at least one CASP; Art 14(5) and 16(2) obtain and hold information on any self-hosted transfer, and above EUR 1,000 assess ownership or control; recital 45 enhanced due diligence. See the MiCA CASP readiness checklist CRM III.G.2 to 3 above AED 3,500; III.G.7.b unhosted wallet risk; III.G.8 sunrise plan; III.H real-time screening, immediate freeze, eight-year records; III.F.3.b 48-hour responses Para 5.3 travel rule between reporting entities, no post-facto submission; para 7.2 onus on the hosting entity for unhosted transfers; paras 7.4 to 7.5 no mixers or anonymity-enhancing tokens; para 5.5 STRs irrespective of amount. See FIU-IND registration in India Not a Trust Services category

SOC 2 is the AICPA’s examination of controls at a service organisation relevant to security, availability, processing integrity, confidentiality or privacy, reported on by a CPA firm under the 2017 Trust Services Criteria (with revised points of focus, 2022). It is an attestation about your controls; it is not a licence, and it does not decide which column you sit in. Primary texts: FinCEN FIN-2019-G001, Regulation (EU) 2023/1114, Regulation (EU) 2022/2554, Regulation (EU) 2023/1113, the VARA Custody Services Rulebook, Technology and Information Rulebook and Compliance and Risk Management Rulebook, the FIU-IND Guidelines of 8 January 2026, the AICPA Trust Services Criteria and the H.R.3633 text as received in the Senate.

Frequently asked questions

Does SOC 2 replace a licence for a self-custody wallet provider?

No. SOC 2 is an attestation, not a licence. It is an AICPA examination in which a CPA firm reports on a service organisation's controls against the Trust Services Criteria for security, availability, processing integrity, confidentiality and privacy, and the AICPA frames the report as assurance for users assessing outsourcing risk. No regulator issues it, and none of the four regimes on this page treats it as a substitute for authorisation or registration. Whether a wallet provider needs a licence or registration is decided by FinCEN's control test, which decides money-transmitter status and the Bank Secrecy Act duties that follow, MiCA's means-of-access definition, VARA's activity rules or FIU-IND's activity-based registration, on the facts of the key architecture. A SOC 2 report is useful evidence about the controls once that classification is made. It does not make the classification.

Which tests decide whether a wallet provider is a custodian?

Each regulator applies its own test. FinCEN asks who owns the value, where it is stored, whether the owner interacts with the payment system directly and whether the intermediary has total independent control over the value; a hosted wallet, a ledger entry in the provider's own books or independent control flips the answer, whatever label the provider uses. MiCA asks whether the provider safekeeps or controls crypto-assets or the means of access to them, including private keys, and recital 83 carves out hardware and software providers of non-custodial wallets. VARA treats client assets as held or controlled by a VASP where the private keys or seed phrase are held or controlled by the VASP. FIU-IND applies the safekeeping-or-administration activity regardless of where the entity sits, and says a smart contract does not relieve the parties who control it. A structure that clears one test does not automatically clear the next. Classification is fact-specific.

Does a non-custodial wallet provider have AML obligations under FinCEN, MiCA, VARA and FIU-IND?

It depends on which side of the perimeter the provider lands, in each market separately. Under FinCEN's 2019 guidance a supplier of wallet software that never accepts or transmits value is engaged in trade, not money transmission; a hosted wallet provider is an account-based money transmitter with Bank Secrecy Act and Funds Travel Rule duties. Under MiCA, recital 83 says hardware and software providers of non-custodial wallets should not fall within the Regulation's scope, and the EU travel rule only applies where a CASP acts on at least one side of a transfer. In Dubai, VARA's AML rules bind licensed VASPs, which must weigh the risk of unhosted wallets and hold originator and beneficiary data above AED 3,500. In India, obligations are activity-based; where a transfer runs between a hosted and an unhosted wallet, the onus sits with the reporting entity hosting the wallet. Figures are as at 12 September 2026.

Is the US CLARITY Act now the test for non-custodial wallet developers?

No. H.R.3633, the Digital Asset Market Clarity Act, would create a safe harbour for non-controlling blockchain developers: section 109 of the House-passed text would provide that such a developer is not treated as a money transmitter solely for publishing software or providing hardware or software to facilitate a customer's own custody, and would define non-controlling as lacking the legal right or the unilateral and independent ability to move users' digital assets without another party's approval. On 15 September 2026 the Senate vote to invoke cloture on the motion to proceed to the bill failed, short of the 60 votes required. Nothing in it is enacted, including its Blockchain Regulatory Certainty Act provisions for non-controlling developers. FinCEN guidance FIN-2019-G001 remains the operative federal money-transmission position.

The one principle under all twelve

Every regulator on this page asks the same three questions in its own words: can any single party, including the platform, move funds without the client’s separate signature; does the platform control any credential that acts as a means of access or a verified-instruction checkpoint; and has the structure been tested against the specific legal standard in every market it operates in. The controls above are how you make the answers true, and how you prove them. The label, the whitepaper and the SOC 2 report are not the analysis; the control structure is. Since 1 July 2026 the EU has no transitional lane for unauthorised providers, and non-EU providers may not serve or solicit EU clients, including business to business, so the EU answer in particular needs to be right before the first EU client, not after.

Next step

Building or buying wallet infrastructure?

The infrastructure describes the controls; the licensing layer decides what they mean in each market. Send us the key architecture and the markets you serve. Infinilex maps it against each market’s perimeter test and the twelve controls above, and where a licence or registration follows, coordinates the route: in the US the filing and opinion work sits with US securities counsel and the SOC 2 report with a CPA firm, in the UAE the regulated filings are signed by the applicant with ADGM- or DIFC-registered counsel where a financial free zone leg is involved, in India the sign-off sits with an Indian advocate, company secretary or chartered accountant, and for the EU, Infinilex quarterbacks, EU local counsel files.

Further reading

Self-custody meets institutional control, with Reah · The Web3 legal readiness checklist · The UAE VASP licensing checklist · Crypto licence requirements by country · VARA licence cost, capital and timeline · MiCA vs VARA · MiCA authorisation

The PDF

Want this as a PDF in your inbox?

Email us and we will send the current version, and the updated one each time the law moves. Or print the page: it is built for paper.

Email me the PDF

This checklist is general information for founders and product teams, not legal advice for your specific platform. Whether a wallet or self-custody product is inside or outside custody licensing is decided on its facts, separately in each market where it is offered, and this page does not assess any specific platform’s architecture, including that of any partner. Thresholds, retention periods and notification clocks are stated as at 12 September 2026, and the status of H.R.3633 as at 18 September 2026, after the failed Senate cloture vote of 15 September 2026; any of them can change. Confirm every point against current law before relying on it, and have your setup reviewed before launch.