Executive Summary
- The hypothetical Indonesian MPC wallet cannot support a software-only launch merely because nobody holds a complete private key. The Markets in Crypto-Assets Regulation (MiCA) covers safekeeping or control of assets or their means of access, including custody arrangements in which the client retains control. (Regulation (EU) 2023/1114 (MiCA), recital 83 and Article 3(1)(17).)
- If the company and recovery provider can replace the user or sign together without the user's authority, the stronger interpretation is regulated custody. A share that cannot move assets alone still requires analysis of its safekeeping function. The exact treatment of restricted non-EU co-signing remains unsettled in ESMA's published question 2933. (MiCA, Article 3(1)(17); ESMA_QA_2933, 2 October 2026, unanswered.)
- A supportable software scope requires a real change in powers. Users must retain their own signing and recovery authority, while the supplier neither safeguards their access material nor operates another regulated service. Social login must not give the supplier a route to take over the wallet. (MiCA, recital 83 and Article 3(1)(16)–(26).)
- For the recommended release using traded MiCA assets, retain provider-assisted recovery through an authorised EU operator that actually supplies custody. Restrict the Indonesian company to technology work. Any downstream provider performing custody must qualify under Article 59; an outsourcing contract cannot confer that permission. (MiCA, Articles 4(5), 59, 73 and 75(9).)
- The swap interface needs a separate service analysis. Receiving and forwarding an order, concluding a trade for a user, dealing against proprietary capital and transferring assets have different statutory tests. A non-custodial wallet can still perform one of those services. (MiCA, Article 3(1)(18)–(26).)
- Indonesian permissions follow the company's actual functions. The amended financial-sector statute expressly addresses wallets where a crypto financial institution holds primary access and transfer control. Pure code supply, active recovery and local trading therefore need distinct treatment. (Law 4/2023, as amended by Law 4/2026, Article 221A and its elucidation; OJK Regulation 27/2024, as amended by OJK Regulation 23/2025, Articles 1–2.)
- A fraudulent recovery requires containment, evidence preservation and separate decisions on client compensation and regulatory reporting. Outsourcing and recovery disclaimers do not remove the EU custodian's statutory responsibility for attributable losses. (MiCA, Articles 73(1) and 75(8); Regulation (EU) 2022/2554 (DORA), Articles 17–19.)
- Launch should follow a demonstrated recovery and exit process, matched permissions, enforceable supplier obligations and lawful access to identity records. The alternative to unresolved provider control is postponing that functionality or redesigning it around user-controlled recovery. (MiCA, Articles 59, 73–75; Regulation (EU) 2016/679 (GDPR), Articles 25, 28 and 44–46.)
The recovery sequence determines the service
The company's ordinary signing process and its lost-device process need separate legal treatment. The hypothetical multi-party computation (MPC) wallet uses a two-of-three arrangement: the user's device and a service co-signer normally participate, while a separate provider holds a recovery share. After identity checks, a recovery workflow can replace the user's share. Classification depends on the powers implemented across that complete process.
For the recommended first release, select fungible cryptoassets already admitted to trading and covered by MiCA. Defer electronic-money tokens, asset-referenced tokens and financial instruments. This is a proposed product limit. Article 4(5) removes the Article 59 authorisation requirement for custody and transfers involving assets whose offers are exempt under Article 4(3), subject to its conditions. Admission to a cryptoasset trading platform prevents reliance on that exemption. The authorisation recommendations below concern the proposed traded-asset release. (MiCA, Articles 2(4)(a), 4(3)–(5).)
At creation, the relevant questions concern who generates the shares, receives copies and controls backup or administrative credentials. During ordinary use, the user and co-signer contribute to authorising a transaction. The co-signer's ability to reject a request may protect the user, create an indispensable service dependency, or form part of safeguarding access. Each role needs to be assessed under MiCA's definition of custody. A displayed balance or a signature threshold alone does not establish who controls the means of access. (MiCA, Article 3(1)(17).)
Recovery changes the analysis when the original device disappears. If the company can instruct the recovery provider to replace the user's share, the user may cease to be indispensable. The same concern arises if the two providers can authorise transfers together. Calling the second company independent does not settle whether common administrators, binding instructions or shared ownership give the wallet company effective access to its share. The assessment must follow each permitted combination of actors, including emergency permissions. (MiCA, Articles 3(1)(17) and 75(3).)
Cancellation and upgrades can alter those combinations. An authenticated user may need a way to stop a pending recovery before new credentials become effective. The company's ability to update the client must be examined separately from powers to change signing policy, substitute a destination or reset access. Ordinary software maintenance does not automatically constitute custody. A deployed administrative route that can replace the user's authority presents a materially stronger control case under Article 3(1)(17).
Exit tests whether the stated allocation survives withdrawal of cooperation. A user-controlled design should let the user move assets using independently controlled access material even if the supplier stops operating. An authorised custody design instead needs the operator's effective return procedures, continuity arrangements and orderly wind-down plan. A support promise cannot cure a design that leaves the necessary recovery authority with an unavailable provider. (MiCA, Articles 73(2), 74 and 75(6).)
MiCA custody includes shared control and safekeeping
The strongest custody case arises where the company and recovery provider can jointly reconstruct effective control. Article 3(1)(17) defines custody through safekeeping or control, on behalf of clients, of cryptoassets or their means of access. The alternatives matter: legal custody does not require ownership of the asset, a complete private key, or an ability to transfer assets without any other participant. A service that protects access material for clients must also be tested against the safekeeping limb. (MiCA, Article 3(1)(17).)
Recital 83 supports a narrower scope for genuine wallet software. It states that providers of non-custodial wallet hardware or software should fall outside MiCA. The same recital expressly contemplates custody in which the client keeps control. Read together, those passages prevent treating a user signature or retained user veto as a universal exemption. The operative service definition still applies to the provider's actual role. (MiCA, recital 83 and Article 3(1)(17).)
For the combined-control variant, the company's recovery authority supplies the decisive connection. The providers hold their shares for the user's wallet and can together replace or bypass the user's contribution. Their service therefore concerns the user's means of access even if no complete key ever exists in one place. This is the stronger interpretation of the statutory wording, rather than an express statutory rule about a particular MPC threshold. Changing the number of companies or renaming a share a recovery credential leaves that reasoning intact where the powers remain equivalent.
The strongest opposing argument concerns a strictly constrained co-signer. A provider might perform a mechanical step only after the user's independent authorisation, with no power to choose a destination, change policy or substitute credentials. That arrangement is closer to technical support, particularly where the provider does not undertake safekeeping. Yet a claim that the user always signs leaves the recovery path unanswered. A provider that keeps essential access material can still fall within the statutory definition. (MiCA, recital 83 and Article 3(1)(17).)
The European Securities and Markets Authority (ESMA) published question 2933 concerning non-EU group entities that co-sign transactions or alter signing policies. Its status is “Forwarded to EC/Public Consultation/Other”, without a published answer. The entry supplies no exemption or binding determination. A restricted holder of a signing share therefore remains a distinct, unresolved configuration; the relevant facts include the purpose of holding the share, enforced limits, alternative signing paths and recovery authority. (ESMA_QA_2933, 2 October 2026.)
A software scope requires user-controlled access
A software-only route is supportable if the supplier's functions remain outside every relevant MiCA service. For this product, the strongest design would leave signing and recovery material under the user's own control. The company would supply the interface and code without keeping customer access material or deciding who replaces a lost signer. A user-held backup or user-controlled recovery mechanism would replace the company's recovery authority. These are proposed changes to the hypothetical service. (MiCA, recital 83 and Article 3(1)(16)–(17).)
Social login could still identify an application account. It should not, by itself, release provider-held material sufficient to take over the wallet. The design would need an independently controlled user authorisation for spending and changes to access. Engineers should demonstrate that production administrators cannot override that requirement, including through remote configuration or recovery tooling. A contractual prohibition on misuse leaves the classification exposed where the supplier retains the operative power.
A developer's general ability to distribute new software does not establish that every software customer has surrendered control. The relevant evidence concerns the actual deployment path and permissions: whether a trusted user-controlled signer independently verifies the transaction, whether changes require effective user approval, and whether an update can extract or replace access material. Keeping unrestricted automatic control over those functions would contradict the proposed software allocation. (MiCA, Article 3(1)(17).)
The commercial cost is a narrower recovery promise. If the user loses every independent recovery factor, the developer cannot promise to restore access through its own authority. If convenient provider-controlled restoration remains central to the product, the authorised-service route better matches that commitment. A supplier's custody powers still require the applicable permission, even if customer terms assign losses to users. (MiCA, Articles 59(1) and 75(1), (3), (8).)
EU custody and outsourced recovery
The preferred route for retaining assisted recovery is an EU operator authorised for the relevant custody service. That entity should contract with the user, control the custody policy and accept the associated client duties. For the initial launch, the Indonesian company should have no production signing share, power to replace user credentials, or authority to override recovery policy. This proposed restriction makes its technology role easier to substantiate; MiCA does not prescribe a universal geographic location for every cryptographic component. (MiCA, Articles 3(1)(17), 59(2), 73 and 75.)
The EU provider can procure software, hosting and identity-verification support. Article 73 requires it to retain responsibility, supervisory access, expertise and the resources needed to oversee the outsourced functions. If a recovery provider itself safeguards or controls client access, Article 75(9) imposes a further condition: the downstream custody provider must qualify under Article 59, and clients must be informed. A provider that merely checks identity without access or recovery authority presents a different service. There is no standalone MiCA permission called recovery. (MiCA, Articles 3(1)(16), 73 and 75(9).)
The Indonesian parent cannot retain the original powers behind an EU contracting entity and treat the arrangement as licensed technology supply. The potential objection is MiCA's exclusion for services supplied exclusively to specified group companies. That exclusion requires its own factual application. It does not establish that an EU custodian can disregard Article 75(9) when another entity supplies custody of its customers' assets. A group contract must identify the real service recipient and the assets controlled; the restricted non-EU co-signing configuration remains unresolved in ESMA's published question. (MiCA, Articles 2(2)(a), 73 and 75(9); ESMA_QA_2933.)
An owned EU subsidiary is the alternative where the group wants to retain the custody business. An Article 63 applicant needs an EU registered office where it performs part of its services, effective EU management and at least one EU-resident director. It must seek permission for each service it will perform. Certain existing financial institutions can instead use Article 60 within its conditions. Incorporating a subsidiary does not itself authorise the Indonesian parent or the new entity to operate. (MiCA, Articles 59–60 and 62–63.)
The economics include permanent prudential safeguards. A standalone custody cryptoasset service provider (CASP) falls within the €125,000 minimum category, subject to the higher requirement of one quarter of the relevant fixed overheads. A new provider uses its first-year projections for the overhead calculation. Eligible own funds, qualifying insurance or their permitted combination can meet the requirement. These safeguards sit alongside staffing, systems and operating expenditure. A trading-platform permission would engage a different minimum category. (MiCA, Article 67 and Annex IV.)
The external-provider route also has costs: supplier restrictions, the operator's charges and dependence on its supported assets and recovery processes. It is preferable here because it can preserve assisted recovery within a defined authorised service. The recommendation changes if the company can prove the user-controlled design, or if the group funds an autonomous authorised operation. If the Indonesian entity must retain custody powers, the proposed technology allocation fails.
EU solicitation and the swap interface require separate decisions
The intended EU retail launch requires a lawful EU service route wherever regulated functions remain. Article 61's exception concerns a client's own exclusive initiative. Targeted promotion by the third-country business, its agents or closely linked persons defeats that premise, despite a declaration in the terms. It also cannot support later marketing of new service or asset types. A planned EU customer-acquisition programme should therefore proceed through the authorised operator. (MiCA, Articles 59 and 61.)
The provider's permission must cover the actual functions and intended Member States. Article 65 governs cross-border notification. MiCA's maximum grandfathering period for qualifying pre-existing providers ended on 1 July 2026; a historical registration cannot support this new launch. Provider selection should examine the official permission, service schedule and cross-border position, together with the proposed outsourcing. The operating state should follow genuine management and service arrangements. (MiCA, Articles 59(2), (6), 65 and 143(3).)
The swap feature should remain outside the first release until its transaction path and operator are settled. A neutral link directing users to another provider is different from a wallet business receiving an order and transmitting it for execution. Selecting a third-party endpoint does not remove that second activity. Concluding a purchase or sale for the user engages execution; contracting with users against the company's own capital engages exchange. Matching multiple buyers and sellers through a managed system can engage trading-platform operation. (MiCA, Article 3(1)(18)–(23).)
Contracts, screens and logs should identify who receives the order, selects the route, agrees the price and becomes the counterparty. Fees are relevant evidence of the commercial role, although charging a fee is not a complete classification test. A provider receiving and transmitting orders also faces the restriction on remuneration for routing orders to a particular execution venue or provider. Personalised token recommendations or discretionary trading would require separate advice or portfolio-management analysis. (MiCA, Articles 3(1)(24)–(25) and 80(2).)
Transfers require their own assessment even where the wallet avoids custody. Article 3(1)(26) concerns moving cryptoassets between addresses or accounts on behalf of another person. The company should distinguish software used by the customer from a service that undertakes that movement. A transfer provider needs the relevant permission and the client agreement required by Article 82. Custody permission alone should not be treated as approval for every swap or transfer feature. (MiCA, Articles 3(1)(26), 59(6) and 82.)
Tokenised financial instruments require a different permission analysis under Article 2(4)(a). Payment functionality and electronic-money tokens need a separate assessment of payment-services requirements, including Article 70(4). Before adding these functions, the operator should document the additional permissions and asset restrictions. (MiCA, Articles 2(4)(a), 3(1)(7) and 70(4).)
Indonesian law distinguishes code supply from operating the wallet
An Indonesian company cannot establish its local position solely by describing revenue as software exports. The financial-sector statute, amended by Law 4/2026, requires crypto financial institutions to hold a business licence from Indonesia's Financial Services Authority (OJK) appropriate to their activities. Its categories include dealers and centralised storage operators. The company's continuing role in signing, recovery and customer access must therefore be classified independently of its EU route. (Law 4/2023 on Financial Sector Development and Strengthening, as amended by Law 4/2026, Articles 221A(1)–(2) and 221C.)
The statute contains a specific wallet distinction. Article 221A(8) requires relevant crypto activity, including specified digital-wallet activity, to be transacted through or reported to a crypto exchange, or both. Its official elucidation identifies wallets used for storage by a crypto financial institution where primary authority to access and control asset movements rests with that institution. Reading the rule with that explanation avoids treating every user-controlled wallet as an institutional storage service. The elucidation defines the wallets addressed by that exchange and reporting provision. Licensing also requires the separate activity analysis under Article 221A(1)–(2) and OJK's rules. (Law 4/2023, as amended by Law 4/2026, Article 221A(1)–(2), (8) and its elucidation.)
The software-supply argument is strongest where the Indonesian company writes and maintains code without holding production shares, approving recovery or controlling withdrawals. Continuing co-signing, destination replacement or power to reconstruct access creates a materially different case. Those functions require classification under OJK's crypto rules and, where relevant, its financial-sector technology innovation rules. Sandbox participation or a pass letter does not authorise full business operations. Neither using MPC nor serving only EU customers establishes an export exemption. (OJK Regulation 27/2024, as amended, Articles 1–2; OJK Regulation 3/2024, Articles 2–4, 10(5) and 15(5).)
OJK Regulation 27/2024 does not make MPC an exclusion. Article 41(5)(b) expressly refers to multi-party computing within regulated storage arrangements. That provision shows that the technology can operate inside the regulated system; it neither approves this design nor makes every remote holder of a signing share a licensed storage operator. The correct classification still depends on the firm's service, counterparties and actual powers. The existing implementing rules continue only insofar consistent with the amended statute. (OJK Regulation 27/2024, Article 41(5)(b); Law 4/2026, Article II(9).)
OJK Regulation 23/2025 amended the definitions, system-control requirements, storage arrangements and permitted dealer activities. OJK Board of Commissioners Member Regulation 3/2026 supplies the current technical implementation, replacing most of the earlier circular while preserving specified reporting provisions temporarily. Historical Bappebti requirements or an older licensing checklist cannot establish the present entry requirements. The recommended technology role should be documented against the current activity rules before production powers are assigned. (OJK Regulation 27/2024, as amended by OJK Regulation 23/2025, Articles 1, 36–37 and 51; OJK Board of Commissioners Member Regulation 3/2026, Articles 1–4.)
Adding Indonesian consumers or a local swap service is a separate commercial decision. The amended dealer provisions address rupiah-to-crypto and crypto-to-crypto activity, storage and transfers. Integration with a licensed dealer also raises the rules governing access, cooperation and supporting activities. A partner's permission does not automatically cover the wallet company's own order flow or custody powers. The company should settle those functions and the applicable approval requirements before enabling the local feature. (OJK Regulation 27/2024, as amended, Articles 51(1), 52(1), (5)–(6) and 102(2)–(3); Law 4/2023, as amended, Article 221C.)
Electronic-system duties remain relevant to the Indonesian operator
A technology role can still involve operating an electronic system. The registration rules cover persons providing, managing or operating a covered electronic system. The company should identify who runs the login, recovery and support systems and register each covered operation through the prescribed process before users access it. An EU customer base does not, by itself, remove the duties of an Indonesian operator. (Government Regulation 71/2019, Articles 1(4), 2 and 6; Minister of Communication and Informatics Regulation 5/2020, as amended by Regulation 10/2021, Articles 2–4.)
Hosting and access locations require a separate decision. Government Regulation 71/2019 permits private electronic-system operators to manage and store data abroad subject to supervision, law-enforcement access and applicable sector rules. Article 37 of the amended OJK Regulation 27/2024 imposes additional Indonesian infrastructure and record requirements on its regulated storage operators. Those sector duties should not be applied automatically to every software exporter, but they become material if the company performs the regulated storage activity. (Government Regulation 71/2019, Article 21; OJK Regulation 27/2024, as amended, Article 37.)
The EU contract should therefore identify the Indonesian service, system operator, data role and permitted production access expressly. It should also require review before the supplier receives new recovery powers or serves a new local market. The contract does not turn an EU permission into Indonesian authority, or an Indonesian licence into a MiCA passport. (MiCA, Articles 59 and 73; Law 4/2023, as amended, Articles 221A(2) and 221C; Government Regulation 71/2019, Article 6.)
The custody agreement must describe recovery and return
The authorised operator's customer agreement must explain what happens when a device is lost. Article 75(1) requires the parties' identity, the service description, custody policy, communications and authentication system, security arrangements, charges and applicable law. For this wallet, those provisions should identify who may request recovery, the required evidence, the approval process and the point at which old credentials cease to work. A general reference to social login would leave the decisive access changes unexplained. (MiCA, Article 75(1).)
The contract should distinguish authenticating an account from authorising a transaction or replacing a signer. A recovery request should trigger checks proportionate to the consequences of replacing access. Independent notification, a defined challenge period and separate approval for exceptional recovery are defensible design recommendations where they reduce fraudulent replacement. Their form and duration must follow the documented risk assessment; MiCA does not prescribe a universal cooling-off period. (MiCA, Article 75(1)(d)–(e) and (3).)
Customer rights also need records outside the blockchain. The custodian must maintain a client-by-client position register and record relevant movements following client instructions as soon as possible. Events likely to create or modify client rights must be recorded immediately. Statements are due at least every three months and on request, with prompt information about operations requiring a client response. A transaction hash should connect to the client's instruction and entitlement; it cannot substitute for that entire record. (MiCA, Article 75(2), (4)–(5).)
Segregation concerns holdings and legal rights. Article 75(7) requires client assets to be separate from the provider's own assets on the distributed ledger, operationally and legally. It also requires clear identification of clients' means of access. Article 70(1) prohibits own-account use of client cryptoassets. The parties should test the chosen custody arrangement against the relevant property and insolvency law before relying on segregation in a failure. Separate device shares do not themselves resolve ownership or creditor recourse. (MiCA, Articles 70(1) and 75(7).)
Return procedures must work after termination, provider failure and a disputed recovery. Article 75(6) requires return of the assets or means of access as soon as possible. The custody arrangement should identify the usable access that will be delivered, the verification required and the receiving address or replacement provider. The Commission's nonbinding answer published in ESMA Q&A 2320 interprets the obligation as return of the same type of asset; conversion requires the client's request and the relevant service permissions. A provider should not promise to settle every withdrawal in cash. (MiCA, Article 75(6); ESMA_QA_2320, updated 18 February 2026.)
A compromised social login requires a separate liability assessment
In the hypothetical failure event, an attacker compromises the social login and triggers recovery without the legitimate user. The first investigation should identify how the attacker passed each control and which actor authorised replacement. The operator should preserve the original request, authentication evidence, approval records, share-rotation events and any resulting transactions. Those records connect the claimed loss to the service and distinguish an unauthorised recovery from a properly instructed movement. (MiCA, Articles 68(9) and 75(2)–(3).)
The custodian is liable under Article 75(8) for loss of cryptoassets or their means of access resulting from an incident attributable to it. The provision caps that liability at the lost asset's market value when the loss occurred. It does not settle the scope of every separate consumer, contractual or data-protection claim. An attacker obtaining a login does not, by itself, determine attribution or the amount of compensable loss. Failed recovery checks, excessive administrator access or an unsafe reset path would connect the event to the custodian's operations. The loss assessment must also address whether access was restored and which assets were actually lost. (MiCA, Article 75(8); GDPR, Article 82.)
The custodian's strongest defence is a demonstrated event independent of its service or operations. Article 75(8) identifies an inherent defect in a distributed ledger outside the provider's control as one possible case. A failure by the login or recovery supplier does not automatically establish that defence: the custodian selected an operational dependency, and Article 73 preserves its responsibility for outsourcing. The incident's cause, the operator's powers and the controls actually applied remain decisive. A recovery disclaimer cannot replace that statutory assessment. (MiCA, Articles 73(1) and 75(8).)
Containment should use powers the operator lawfully possesses. It can disable compromised service credentials, suspend its own affected signing path and stop a pending replacement where the design permits. After reliable re-identification, it should revoke compromised access and restore the authorised configuration. Any movement to a replacement wallet needs valid authority and a recorded basis. The response cannot assume a power to reverse completed blockchain transactions or take assets from an external wallet. (MiCA, Articles 75(1)–(3), (6) and 82(1); DORA, Articles 11–12 and 17.)
Supplier reimbursement should be agreed separately. The recovery provider's contract needs duties to preserve evidence, assist containment, disclose subcontractors and cooperate with investigations and claims. Liability terms should address faulty verification, unauthorised resets, confidentiality breaches and failure to assist exit. An indemnity may allocate losses between businesses; it does not remove the customer's rights against the regulated provider. (MiCA, Articles 73 and 75(8).)
An Indonesian crypto financial institution has its own consumer-loss rule. Article 221A(11) addresses loss caused by error, negligence or breach of laws or regulations in the financial services sector or an agreement by specified controllers, shareholders, officers, staff and third parties representing or working for it. The provision should not be treated as automatically applying to an Indonesian company whose only role is supplying code. (Law 4/2023, as amended by Law 4/2026, Article 221A(11).)
Consumer terms also require separate scrutiny. Under Rome I, a choice of foreign law cannot deprive a targeted consumer of the mandatory protections that Article 6 preserves. The consumer-jurisdiction rules constrain advance forum clauses, while unfair standard terms can be non-binding. These rules prevent relying on an Indonesian-law clause or a broad waiver as a complete response to an EU retail claim. The enforceability of any particular limitation needs the relevant national law and contract. (Regulation (EC) 593/2008, Article 6; Regulation (EU) 1215/2012, Articles 17–19; Directive 93/13/EEC, Articles 3 and 6.)
Operational duties require evidence of the recovery controls
The Digital Operational Resilience Act (DORA) applies to authorised cryptoasset service providers within its scope. It requires the EU operator to manage information and communication technology (ICT) risk, maintain response and recovery capabilities, test its controls and manage third-party dependencies. Outsourcing the software to Indonesia leaves the operator responsible. The supplier's practical obligations should appear in the contract and access design; describing it as a technology partner does not transfer the regulated duties. (DORA, Articles 2(1)(f), 5–6, 11–12, 24 and 28–30.)
The control evidence should cover every production, backup, recovery and administrative credential. Commission Delegated Regulation 2024/1774 addresses cryptographic-key management, protected logging, identity management and access controls. For this product, the operator should retain evidence of permitted signing combinations, privilege grants, policy changes, recovery approvals and revocations. Logs should identify the event and responsible actor without exposing private keys, secret shares or unnecessary identity-document contents. (Commission Delegated Regulation (EU) 2024/1774, Articles 6–7, 12 and 20–21; GDPR, Articles 5(1)(c) and 32.)
Recovery tests should include a stolen social account, lost device, unavailable co-signer, disputed identity and failure of the recovery provider. A separate exit test should establish that the operator can recover records and continue returning client assets after terminating the supplier. These are proposed tests of this service's identified dependencies. The regulatory duties require effective and proportionate controls; completing a checklist does not certify the cryptography or establish that a particular threshold is secure. (DORA, Articles 11–12, 24–25 and 28(8); MiCA, Articles 73(2) and 75(3), (6).)
The outsourcing agreement needs a complete service description, data and service locations, incident assistance, access to records and enforceable termination rights. Where the service supports a critical or important function, the stronger DORA terms include defined service levels, audit and inspection rights, continuity testing and an adequate transition period. The operator must assess permitted subcontracting and remain able to supervise the chain. Licentium's custody resilience analysis addresses the wider operational obligations of an authorised custodian. (DORA, Articles 28–30; Commission Delegated Regulation (EU) 2025/532, Articles 3–6; MiCA, Article 73.)
An incident must be classified under DORA independently of the client-loss decision. A major ICT incident requires regulatory reporting. The ordinary initial deadline is as early as possible, within four hours of major classification and within 24 hours of awareness. If classification occurs after the first 24 hours, the four-hour limit then applies. The ordinary intermediate deadline is 72 hours after the initial notification, with updates required without undue delay and when regular activities are restored. The final report is due within one month of the intermediate or latest updated intermediate report. Applicable timing exceptions need to be built into the operator's reporting procedure. (DORA, Articles 17–19; Commission Delegated Regulations (EU) 2024/1772, Articles 6 and 8–9, and 2025/301, Article 5.)
Where a major incident affects clients' financial interests, DORA also requires prompt client information. The operator needs a separate complaints procedure and a route to investigate the customer's demand for restoration or compensation. The response should distinguish confirmed facts, protective steps and unresolved attribution. Neither a regulatory notification nor a restored login proves that the customer's asset claim has been resolved. (DORA, Article 19(3); MiCA, Articles 71 and 75(8).)
Identity records require a lawful cross-border access model
The wallet's social-login identifiers, identity documents and recovery records require their own data-protection analysis. The General Data Protection Regulation (GDPR) applies to personal data processing in the context of the activities of the EU operator's establishment. It can also apply directly to an Indonesian business offering services to people in the EU, even where a particular wallet function falls outside MiCA. An overseas business within Article 3(2) must also assess the EU-representative requirement and its limited exceptions. (GDPR, Articles 3 and 27.)
The parties must allocate data roles by their actual decisions. An Indonesian supplier processing recovery evidence solely on the custodian's documented instructions would ordinarily act as a processor for that activity. If it determines separate fraud-screening or account-use purposes, it must assess its own controller role. Processor terms need documented instructions, confidentiality, security, subprocessor controls, assistance, audit rights and return or deletion of data. A contract label cannot replace the factual allocation. (GDPR, Articles 4(7)–(8), 26 and 28.)
The operator should identify a lawful basis for each purpose and collect only the evidence needed. Routine login data, statutory identity checks and recovery investigations need not share the same legal basis or retention period. A photograph is not automatically special-category biometric data; the additional Article 9 conditions matter where biometric processing uniquely identifies a person. A data-protection impact assessment is required where the planned processing is likely to create high risk. The combined identity and asset-access design should be assessed before deployment. (GDPR, Articles 5–6, 9, 25 and 35.)
Public blockchain information can be personal data where it relates to an identifiable person. Linking an address to the user's social account or identity record can make that connection direct. Identity documents and recovery secrets should remain outside the public ledger, with restricted access and a documented deletion schedule. The operator should preserve the records needed to reconstruct instructions without publishing personal evidence or secret signing material. (GDPR, Articles 4(1), 5, 25 and 32; European Data Protection Board (EDPB), Guidelines 02/2025 on processing personal data through blockchain technologies, final version, 7 July 2026, nonbinding.)
Making EU-held data available to a separate Indonesian support provider can constitute an international transfer, including remote access. Indonesia has no European Commission adequacy decision. The parties therefore need an applicable Chapter V mechanism, together with the ordinary processing basis. Standard contractual clauses are a possible route where their scope and modules fit the actual parties and processing. They also require an assessment of destination-country laws and practices, with supplementary safeguards where needed. (GDPR, Articles 44–46; European Commission, Adequacy decisions, accessed 23 October 2026; Commission Implementing Decision (EU) 2021/914, Article 1 and Annex, clause 14; EDPB, Guidelines 05/2021, final version, paragraphs 9 and 15–18, nonbinding.)
A supplier already directly subject to GDPR for the imported processing cannot automatically use the 2021 clauses as though that scope condition were absent. The contract must identify another applicable transfer route or a structure within the clauses' permitted scope. Nor does consent to wallet recovery provide a general derogation for routine overseas support. The proposed technology arrangement should minimise the identity data visible in Indonesia and keep any necessary access within documented purposes and permissions. (Commission Implementing Decision (EU) 2021/914, Article 1(1); GDPR, Articles 28, 46 and 49.)
If the compromised login also causes a personal-data breach, GDPR reporting runs separately from DORA. The controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours of awareness unless the breach is unlikely to create a risk to individuals. High risk can require communication to affected people without undue delay, subject to Article 34's exceptions. The processor must inform the controller without undue delay. Supplier escalation terms should permit these decisions before the relevant deadlines. (GDPR, Articles 33–34.)
Processing carried out in Indonesia also engages the Indonesian Personal Data Protection Law within its territorial scope. The parties must identify lawful purposes and bases, apply security controls and distinguish controller decisions from processing on instructions. For transfers from Indonesia, Article 56 establishes a sequence: equivalent or higher protection in the recipient country, adequate binding safeguards, then consent where the preceding conditions are unmet. The EU transfer arrangement does not automatically discharge that separate Indonesian duty. Applicable ministerial coordination requirements also need to be included in the transfer process. (Law 27/2022, Articles 2, 20, 27–28, 35–39, 51 and 56; Minister of Communication and Informatics Regulation 20/2016, Article 22, subject to Law 27/2022, Article 75.)
The Indonesian breach obligation has its own wording. Where personal-data protection fails, Article 46 requires the controller to give written notice to the data subject and the institution specified by the Law no later than three times 24 hours. The incident procedure must implement that duty alongside GDPR and DORA, without assuming their triggers and exceptions are identical. Recovery evidence should be preserved for defined legal and investigative purposes, with a record-specific retention schedule. (Law 27/2022, Articles 27–28, 46 and 51; GDPR, Articles 5 and 33–34.)
Transfers to self-hosted wallets still require screening
The authorised operator must assess the Transfer of Funds Regulation whenever the transaction falls within its scope. Regulation 2023/1113 applies to covered cryptoasset transfers involving a CASP with its registered office in the EU. A self-hosted address is a distributed-ledger address unlinked to a CASP or a non-EU entity providing similar services. A person-to-person transfer without CASP involvement is excluded, but a transfer between a customer and a CASP does not become exempt because one address is self-hosted. The recovery and exit design must preserve the information and checks required for the actual transfer. (Regulation (EU) 2023/1113, Articles 2–3 and 14–16.)
For transfers exceeding €1,000 to or from a self-hosted address, the relevant provider must take adequate measures to assess the customer's ownership or control of that address. That threshold does not create a general exemption for smaller transfers. The operator also needs controls implementing applicable Union and national restrictive measures. Following a fraudulent recovery, a request to move assets to a new address should receive the checks required by the real sender, recipient and transaction, without assuming that the successful login proves lawful ownership. (Regulation (EU) 2023/1113, Articles 14(5), 16(2) and 23.)
Retention should be assigned by record type. MiCA generally requires relevant service records for five years, extending to a maximum of seven years at a competent authority's timely request. The Transfer of Funds Regulation requires five-year retention of its information, followed by deletion unless a permitted national extension applies. It also prohibits commercial reuse of personal data collected for that Regulation. The operator should reconcile those duties with GDPR's storage limitation rather than retaining every identity document indefinitely. (MiCA, Article 68(9); Regulation (EU) 2023/1113, Articles 25–26; GDPR, Article 5(1)(e).)
The launch sequence must preserve customer exit
The first implementation step is to approve an operating specification for each actor and each wallet state. Engineers should demonstrate creation, ordinary signing, recovery, cancellation, upgrades, compromise and exit. The specification should identify every usable share, administrative permission and policy override, including combinations under common control. Legal classification should be attached to that demonstrated configuration and reopened when a change gives a supplier new powers. (MiCA, Articles 3(1)(17), 62(2), 68 and 73.)
Next, select the commercial route and execute matching agreements. For the preferred assisted-recovery release, the authorised operator must accept the customer duties and control the live custody service. Its technology and recovery contracts should allocate approvals, incident cooperation, evidence access and transition assistance. The company should defer the swap interface until an identified provider's permissions and the complete order path support it. The user-controlled alternative requires a different recovery promise and evidence that suppliers have no custody function. (MiCA, Articles 59, 73, 75 and 80–82.)
Before onboarding, the operator should demonstrate a return of assets after the Indonesian supplier becomes unavailable. The test should reconcile the customer's entitlement, validate replacement access and preserve necessary records while revoking obsolete credentials. If the providers can still replace the user through an unresolved or unauthorised service, live use of that configuration should wait. Development can continue while the parties remove those powers or place the service with a provider whose permission and operating controls cover it. (MiCA, Articles 59(1), 73(2), 74 and 75(6).)