A UAE technology company plans to use credentials from European Digital Identity Wallets (EUDI Wallets) when customers apply for accounts supplied by an EU financial institution. Can the foreign company request those credentials, which onboarding duties must the institution retain, and what customer data may reach each company? This hypothetical uses a mainland Dubai company, a German-authorised electronic-money institution and an initial service for adults resident in Germany. The institution contracts with the customer for the regulated payment account. The UAE company controls the branded app, navigation and its own analytics purposes. Three variants are compared: the institution requests credentials and returns a result (A); the UAE firm seeks its own relying-party status and supplies evidence (B); or an identity vendor verifies for both organisations (C). The account provider retains its onboarding responsibility in each arrangement. The comparison also addresses corporate identification, representative authority, beneficial ownership and funding checks.
Executive Summary
- The preferred arrangement makes the German institution the registered wallet relying party. Its identity request then serves its own account-opening duties. The UAE app can initiate that process, but receipt of a customer-linked result requires a separate lawful purpose and international-transfer route. (Regulation (EU) No 910/2014, as amended by Regulation (EU) 2024/1183, Article 5b; Regulation (EU) 2016/679, Articles 5, 6 and 44–46.)
- Foreign ownership does not disqualify a relying party. Registration follows establishment in a Member State. A UAE-only company cannot treat that rule as permission to register in any national portal. A genuinely established EU subsidiary would register in its own name; the parent's rights would remain distinct. (Regulation (EU) No 910/2014, Articles 3(6) and 5b(1)–(2); Implementing Regulation (EU) 2025/848, Article 3 and Annex I, point 4.)
- A wallet presentation can evidence identity attributes within an accepted national identification method. The German institution must still complete the remaining customer due diligence, assess risk and control account acceptance. Delegation can cover execution; responsibility remains with the institution. (German Money Laundering Act, §§ 10–13 and 17; Directive (EU) 2015/849, Articles 13 and 25–29.)
- The institution should receive the required identity and residential-address information with the evidence needed to validate it. The UAE app ordinarily needs much less. A linked approval flag remains personal data, and wallet approval does not supply every GDPR legal basis. (Regulation (EU) 2016/679, Articles 4(1), 5, 6 and 9; Implementing Regulation (EU) 2024/2977, Article 3a.)
- A vendor can operate verification for the institution. If it acts as a wallet intermediary, it is itself a relying party and may not store data about the transaction's content. A shared, reusable identity vault creates a different legal problem from transient verification. (Regulation (EU) No 910/2014, Article 5b(10).)
- Production availability and acceptance duties have different dates. Member States must provide wallets by 24 December 2026; the covered private-sector acceptance duty runs to 24 December 2027. Germany's announced public launch is early January 2027. Those dates do not establish the readiness of a particular wallet, issuer or onboarding method. (Regulation (EU) No 910/2014, Articles 5a(1) and 5f(2); Implementing Regulations (EU) 2024/2977, Article 6, 2024/2979, Article 15, and 2024/2981, Article 22; Federal Government, “Die digitale Brieftasche kommt”, 15 October 2026.)
- Deployment should begin with synthetic testing and a partner-controlled identification flow. Customer-linked UAE callbacks, corporate onboarding and additional Member States should follow separate release decisions. Each expansion must satisfy the applicable identification, data and financial-service conditions. (German Money Laundering Act, §§ 10–13 and 17; Regulation (EU) 2016/679, Articles 25, 35 and 44–46.)
The identity wallet and the regulated account have different functions
The EUDI Wallet is the customer's means of holding and presenting identity data, attributes and related electronic credentials. The regulated payment account or electronic-money wallet is the financial product supplied by the German institution. Holding an identity credential gives the customer a way to prove particular facts. It does not make the wallet provider the account provider or authorise the UAE company to supply the financial product. (Regulation (EU) No 910/2014, Article 3(42) and Article 5a; Directive 2009/110/EC, Article 2(2); Directive (EU) 2015/2366, Articles 4(12) and 37.)
Several legal roles can sit behind one branded screen. The issuer attests the identity or address information. The wallet provider supplies the customer's wallet. The relying party requests and relies on a presentation for its service. The German institution performs customer due diligence as the account provider. A verification contractor can execute agreed checks, while a GDPR controller decides a processing purpose and its essential means. The same company can occupy several roles, but a contract assigning one role cannot settle every other classification. (Regulation (EU) No 910/2014, Articles 3(6), 5a and 5b; German Money Laundering Act, §§ 2 and 17; Regulation (EU) 2016/679, Article 4(7)–(8).)
The three variants therefore answer related but different design questions. A puts the institution in the relying-party position. B adds the foreign group as a requesting party through a legally available structure. C specifies a vendor's role in carrying out verification for the two organisations. A can use C's technical supplier, and B can also employ that supplier. The decisive comparison concerns the actual recipient, verification task and evidence path, rather than three mutually exclusive product labels. Each combined arrangement must satisfy the duties attached to the functions it contains. (Regulation (EU) No 910/2014, Article 5b(9)–(10); German Money Laundering Act, § 17; Regulation (EU) 2016/679, Articles 26 and 28.)
Registration follows establishment and the actual relying party
The UAE company can participate through the German institution without becoming the institution's wallet relying party. Direct registration presents a separate establishment question. Article 5b requires a relying party intending to use wallets for public or private services to register where it is established. The registration information identifies that Member State. The implementing rules require its physical establishment address. Nationality and foreign ownership are not themselves the statutory test. (Regulation (EU) No 910/2014, Articles 3(6) and 5b(1)–(2); Implementing Regulation (EU) 2025/848, Article 3(1) and Annex I, points 1–4.)
A UAE-only applicant has no ordinary registration route based merely on an EU customer base. A separately incorporated EU subsidiary with a real establishment can seek registration as that subsidiary. It must actually perform the declared relying-party function. Whether a branch of the UAE legal person satisfies a national registration policy depends on that establishment and policy. A postal address, testing account or GDPR representative does not by itself establish the required business presence. The representative under GDPR Article 27 does not create an establishment for Article 3(1). (Implementing Regulation (EU) 2025/848, Articles 3–4; EDPB Guidelines 3/2018, version 2.1, section 4.)
Germany's official participation guidance distinguishes testing from operation. Sandbox participation is possible without a German seat. For the national registration process at launch, the guidance requires the participant to be based in Germany. That operational statement does not define every legally sufficient branch structure. Nor does it prohibit cross-border use by a relying party properly registered in another Member State. A pilot invitation cannot replace registration under the applicable national policy. (German EUDI Wallet programme, Ecosystem Knowledge Center, “Who can join” and “Location and service”; Regulation (EU) No 910/2014, Article 5b(1).)
Registration also does not authorise every proposed use of data. The July 2026 amendment requires automated collection of the declared service, attribute and intended-use information for transparency, without pre-authorisation of those fields. Other registration checks remain. The relying party remains bound by its declared requests, GDPR and financial-sector law. A successful registration therefore cannot establish that collecting a portrait, retaining an address or opening a regulated account is lawful. (Implementing Regulation (EU) 2025/848, Article 6(3)–(3a) and (5), as amended by Implementing Regulation (EU) 2026/1730, Article 1(1)–(3); Regulation (EU) No 910/2014, Article 5b(3)–(4).)
Production dates do not establish customer coverage
The institution should approve production use by wallet solution, issuer and accepted credential. The statutory wallet-provision deadline is 24 December 2026, derived from the implementing acts that entered into force on 24 December 2024. Germany has announced an early January 2027 public launch and a gradual expansion of functions. Initial German person-identification access depends on supported official identity documents and their electronic-identification capability. Residence in Germany alone does not establish eligibility for every German credential. (Regulation (EU) No 910/2014, Article 5a(1); Implementing Regulations (EU) 2024/2977, Article 6, 2024/2979, Article 15, and 2024/2981, Article 22; German EUDI Wallet programme, FAQ; Federal Government, “Die digitale Brieftasche kommt”, 15 October 2026.)
Estonia's published plan illustrates another operational distinction. In July 2026, its relying-party-register minimum viable product was scheduled for late 2026 or early 2027, with registration following availability. Its own wallet procurement and its capacity to support acceptance of other Member States' wallets are separate workstreams. On 1 October 2026, the Ministry of Justice and Digital Affairs announced that Estonia's own public wallet rollout is planned for 2028. TARA is being updated for public-service readiness to accept other Member States' certified wallets from the end of 2026. Neither those timetables nor Germany's sandbox proves that every Member State has a live consumer wallet and production registration service. (Estonian Information System Authority, “EUDI Wallet”, updated 22 July 2026; Estonian Ministry of Justice and Digital Affairs, “Valitsus kiitis heaks seaduseelnõu Euroopa Liidu digiidentiteedikukru kasutuselevõtuks Eestis”, 1 October 2026.)
The private-sector acceptance duty has narrower conditions than a general instruction to accept wallets today. Article 5f(2) covers private relying parties, including financial-service providers, where Union or national law or a contract requires strong user authentication for online identification. It excludes microenterprises and small enterprises and requires acceptance upon the user's voluntary request within the statutory 36-month period, ending 24 December 2027. Wallet use remains voluntary, with other identification and authentication means available. (Regulation (EU) No 910/2014, Articles 5a(15) and 5f(2).)
The registration rules apply from 24 December 2026. Their 2026 amendment makes automated registration-certificate issuance mandatory. A different amendment defers the specified wallet-side authentication and validation of registration certificates until 11 August 2028. That delay does not remove relying-party registration duties or permission limits. The design must distinguish a relying-party access certificate from a registration certificate and from the wallet's own certification. (Implementing Regulation (EU) 2025/848, Articles 7–8 and 11, as amended by Implementing Regulation (EU) 2026/1730; Implementing Regulation (EU) 2024/2982, Articles 3(4) and 8, as amended by Implementing Regulation (EU) 2026/1731, Article 4(5).)
An access certificate identifies the relying party or service and the public key used for request authentication. The requesting system must prove possession of the corresponding private key through the applicable protocol. A registration certificate records the declared role, intended use and associated requested data. It provides transparency about the request but does not approve the lawfulness of its purpose. Neither certificate establishes that the wallet solution has been certified or that the institution has completed customer due diligence. (Implementing Regulation (EU) 2025/848, Articles 7–8 and Annexes IV–V, as amended by Implementing Regulation (EU) 2026/1730; Regulation (EU) No 910/2014, Articles 5b and 5c.)
The institution retains the account-opening decision and AML responsibility
The proposed account-opening policy should require completed identification and verification through a lawful German method before opening. German law has a limited exception allowing completion during establishment where its low-risk conditions are met; this design does not use it. The institution must also establish the relationship's purpose, identify any beneficial owner, assess relevant risks and conduct ongoing monitoring. A valid identity credential supplies evidence for part of that work. It does not establish the customer's business purpose, explain transaction funding or decide whether a relationship is acceptable. (German Money Laundering Act, §§ 10(1), 10(9) and 11(1); Directive (EU) 2015/849, Articles 13–14.)
German law separates the information collected, the permitted identification evidence and the verification procedure. Sections 12 and 13 govern the ordinary identification route. Section 14 permits a different verification route when its assessed lower-risk conditions are satisfied. Existing routes include specified official documents, the statutory electronic-identification procedure, qualified electronic signatures with additional prescribed checks, and notified electronic-identification means at assurance level high. Wallet certification alone does not select one of those routes. EUDI Wallets are exempt from the notification process under eIDAS Article 9, so their legal status does not automatically satisfy a German route expressly referring to that process. (German Money Laundering Act, §§ 11(4), 12(1), 13 and 14; Regulation (EU) No 910/2014, Article 5a(22).)
The institution must identify the applicable lawful method and document how the exact presentation meets it. An ordinary risk assessment cannot add a new method to § 12. Section 14(2), point 2, expressly permits suitable, credible and independent documents or data for simplified verification, departing from §§ 12 and 13. That route requires the documented lower-risk assessment and safeguards in § 14; wallet possession or German residence does not itself establish them. The proposed ordinary launch uses a permitted identification procedure until its wallet-based method satisfies the applicable route. Wallet attributes can assist that procedure without replacing its required evidence. (German Money Laundering Act, §§ 12–14; EBA Guidelines EBA/GL/2022/15, paragraphs 9–17, 23–26 and 54.)
The Bundestag adopted the Digitale Identitätengesetz bill on 15 October 2026. The adopted proposal adds a dedicated wallet method in § 12(1), point 4a, with related verification records. It also removes the reference-account transaction from the qualified-signature route. The current § 12 signature route requires signature validation and the prescribed transaction from a qualifying account in the customer's name. The bill ties commencement to promulgation. Parliamentary adoption therefore does not, by itself, permit an institution to apply the proposed method. The launch policy must use the operative method and its evidence requirements. (German Money Laundering Act, § 12(1); Bundestag, 15 October 2026, adoption of BT-Drs. 21/7408 as amended by BT-Drs. 21/8617; BT-Drs. 21/7408, Articles 6 and 14.)
The institution need not personally perform every technical check. Reliance on eligible third parties and contractual outsourcing are distinct routes. Eligible reliance requires the conditions in § 17(1)–(3), including immediate receipt of the necessary information and access to supporting copies on request as prescribed. An ordinary technology company does not become an eligible regulated third party by verifying a wallet. Section 17(5) permits suitable contractors to carry out specified measures under contract; their acts are attributed to the institution. The institution must assess reliability and supervise performance, including sample checks. (German Money Laundering Act, § 17(1)–(7); Directive (EU) 2015/849, Articles 25–29.)
The institution should retain authority over required fields, accepted methods, exceptions, risk acceptance and remediation. Its approved policies must also govern ongoing monitoring and suspicious-transaction reporting. Outsourcing must preserve management control and supervision. This permits automated checks and vendor assistance while keeping responsibility with the account provider. (German Money Laundering Act, §§ 6, 10, 17(6)–(7) and 43; EBA Guidelines EBA/GL/2022/15, paragraphs 9–12, 18–22 and 46–49.)
The current German duties govern the initial design. The new EU Anti-Money Laundering Regulation applies generally from 10 July 2027. Any launch or expansion crossing that date needs a fresh rules-to-process assessment, including the new outsourcing and customer-due-diligence provisions. Treating the entire 2024 Regulation as already applicable would misstate the operating rules. (Regulation (EU) 2024/1624, Articles 18, 19–28 and 90.)
Request attributes for a stated evidential purpose
For the proposed ordinary adult account, the institution needs given names, surname, birthplace, date of birth, nationality and residential address. The revised natural-person identification data (PID) dataset contains the first five fields as mandatory attributes. Address remains optional. Its specified meaning can include a residence or contact address, so an address field cannot automatically prove the customer's residential address. Before accepting the credential, the institution must check its issuer's meaning and obtain suitable evidence for any required fact it does not establish. (German Money Laundering Act, § 11(4), point 1; Implementing Regulation (EU) 2024/2977, Annex, as replaced by Implementing Regulation (EU) 2026/1731, Annex I.)
The request should list those six identity and address categories, plus only the verification metadata needed for the approved method. A full date of birth may be necessary for statutory identification even where an age-over-18 assertion would suffice for a different service. The institution should not request a personal administrative number by default. Collection must satisfy any applicable national conditions and the necessity of the particular purpose. Email and telephone details required for account communications should be collected separately with their own explanation. (Regulation (EU) 2016/679, Articles 5(1)(b)–(c), 6 and 87; Implementing Regulation (EU) 2024/2977, Annex.)
The UAE app ordinarily needs no copy of the PID, address credential, national identifier or portrait. Once the transfer conditions are met, it may receive a transaction-scoped reference and the minimum next-action or completion status required to operate the agreed app service. The parties should document why each field is necessary. Detailed screening matches, source-of-funds documents and suspicion narratives should remain within the institution's controlled compliance process. German restrictions on disclosing suspicious-transaction information also apply. (Regulation (EU) 2016/679, Articles 5–6; German Money Laundering Act, §§ 11a, 43 and 47.)
Portraits require a distinct decision. The amended PID dataset's portrait-inclusion requirement applies from 11 August 2028. Member States may provide an opt-out from that inclusion. It does not establish that a portrait is available for today's proposed presentation. On-device biometric unlocking does not itself mean that the institution receives a face template. If the identification method requires facial matching, the parties must establish both a GDPR Article 6 basis and an Article 9 condition for biometric identification. (Implementing Regulation (EU) 2024/2977, Annex; Implementing Regulation (EU) 2026/1731, recitals 2–3 and Annex I; Regulation (EU) 2016/679, Articles 4(14) and 9.)
The wallet must warn the user and obtain specific confirmation before presenting a portrait. Selective disclosure applies to the portrait as it does to the other PID attributes. These Article 3a safeguards apply from 11 August 2026; the later mandatory-inclusion date does not postpone them. That confirmation is a technical safeguard, not the legal basis for every subsequent use. The amended rules permit relying-party portrait retention only where processing is necessary for identification and authentication, or is provided for by Union or national law, in either case consistently with Union data-protection law. They permit third-country transfers only where GDPR permits them. The proposed launch should therefore omit portraits and separate liveness recordings unless the selected lawful identification method requires them and the additional conditions are met. (Implementing Regulation (EU) 2024/2977, Article 3a; Implementing Regulation (EU) 2026/1731, recital 2.)
Technical validation must be attributable to the institution
An attribute value and proof of that value perform different jobs. A name copied into a form is usable text. The surrounding credential and presentation can establish who attested it, whether it was altered, and whether this response belongs to the current request. A verification service must preserve the evidence required by the institution's chosen method when it converts a presentation into account fields. The receiving institution must be able to trace those fields to the verification performed for its decision. (Regulation (EU) No 910/2014, Article 5b(9); German Money Laundering Act, §§ 8 and 12–13; EBA Guidelines EBA/GL/2022/15, paragraph 26.)
The relying party must authenticate and validate the presented identification data and attestations. Production verification needs several distinct trust checks. The certified-wallet list concerns the wallet solution. The notified trusted-entity lists identify authorised ecosystem actors and their roles. The national registry identifies the relying party and its declared activity. Article 22 trusted lists establish qualified trust-service status where a qualified attestation or signature is used. These records serve different purposes; a logo or a single successful signature check cannot replace them. (Regulation (EU) No 910/2014, Articles 5b(9), 5d and 22; Implementing Regulation (EU) 2024/2980, Articles 3–5 and Annex II, as amended by Implementing Regulation (EU) 2026/1731.)
A separate address attestation requires its own classification. PID uses the recognised PID-provider trust route. A qualified electronic attestation of attributes requires the relevant provider and qualified-service status in the Article 22 trusted-list system. An attestation issued by or for a public body responsible for an authentic source follows the distinct Article 45f provider regime. An ordinary electronic attestation requires an accepted issuer and evidence policy; storage in a wallet does not make it qualified. The institution must identify the applicable issuance and status rules, including Implementing Regulation 2025/1569 as amended by Regulation 2026/1735. The latter amendment's authentic-source interface provision in Article 1(3) applies from 1 January 2027. (Regulation (EU) No 910/2014, Articles 22 and 45f; Implementing Regulation (EU) 2024/2980, Articles 3–5; Implementing Regulation (EU) 2025/1569, Articles 3–6 and 9; Implementing Regulation (EU) 2026/1735, Articles 1–2.)
Article 45b protects an electronic attestation from rejection solely because it is electronic or lacks qualified status. Qualified and qualifying public-body attestations have the legal effect of lawfully issued paper attestations. Those rules preserve the effect of the attested facts; they do not establish that a contact address is a residential address or select a lawful German identification method. The qualified provider's authentic-source verification arrangements also give the UAE app no general right to query population registers. Its rights remain those attached to its own lawful service and declared request. (Regulation (EU) No 910/2014, Articles 45b–45f; German Money Laundering Act, §§ 11–14.)
The institution's acceptance profile should specify the credential format, authorised issuer, supported attributes and assurance requirements. The verifier should check signatures and trust chains, holder or wallet binding, validity periods, applicable status information and the correspondence between the request and response. Session-bound challenges and audience checks should prevent replay or delivery to a different recipient. These are proposed controls for implementing the legal validation duty and the institution's approved onboarding method. (Regulation (EU) No 910/2014, Article 5b(9); Implementing Regulations (EU) 2024/2977, Articles 3–5, and 2024/2982, Articles 3–5; EBA Guidelines EBA/GL/2022/15, paragraphs 13–17 and 54.)
When PID and a separate address attestation are combined, the verifier must establish that they concern the same person through the accepted evidence and profile. Their presence in one response is insufficient by itself. The Commission's Architecture and Reference Framework describes PID-provider lifecycle checks that can make PID status an indirect source of wallet-unit revocation assurance. It does not prescribe a direct wallet-unit-attestation query by every relying party on every presentation. A separate attribute issuer may supply different assurances, which the institution must assess for its chosen method. (European Digital Identity Wallet Architecture and Reference Framework, version 3.0.0, sections 6.6.3.10–6.6.3.12; Implementing Regulation (EU) 2024/2977, Article 5.)
The status policy must distinguish valid, revoked, expired and unavailable evidence. An unavailable or stale response is not a positive non-revocation result. The institution should specify retry, a lawful alternative method and any risk decision its approved process permits. The applicable rules allow relevant credentials valid for 24 hours or less without the revocation mechanism required for longer validity. The service must therefore use the actual credential's permitted mechanism and freshness requirements, without inventing a universal live-issuer query. (Implementing Regulation (EU) 2024/2977, Article 5; Implementing Regulation (EU) 2025/1569, Article 4, as amended by Implementing Regulation (EU) 2026/1735; European Digital Identity Wallet Architecture and Reference Framework, section 6.6.3.7.)
The evidence record should show what the institution relied on at the decision time. It should contain the required verified values, issuer and credential references, relevant trust and status results, the request and session reference, verification time, method version and exception outcome. Retain the supporting evidence required by the chosen method in readable form. Minimise reusable presentations and avoid retaining unrelated attributes merely because the protocol delivered them. A vendor's unexplained “passed” flag cannot demonstrate the underlying checks to the institution or supervisor. (German Money Laundering Act, §§ 8 and 17; EBA Guidelines EBA/GL/2022/15, paragraphs 26 and 46–49.)
Corporate onboarding requires separate ownership and authority evidence
A business application involves several separate propositions. The company exists, the presenter is a particular person, that person can bind the company for this account, and identified natural persons ultimately own or control it. Each proposition needs appropriate evidence. The representative's personal wallet principally addresses personal identity. A company or mandate attestation can address the facts within its actual scope, if the institution can use and validate that evidence through the applicable process. A successful personal presentation cannot supply every missing company fact. (German Money Laundering Act, §§ 3, 10(1), 11(4)–(5) and 12(2)–(3); EBA Guidelines EBA/GL/2022/15, paragraphs 29–31.)
A representative's wallet can identify the representative. A legal-person credential can evidence the company attributes actually attested. Neither establishes the complete ownership chain or the representative's authority merely because a human presented it. The revised legal-person PID dataset requires the legal name and a persistent unique identifier; other company fields have their own availability and meaning. The institution must collect the company information required by German law and verify it through the prescribed corporate evidence. (Implementing Regulation (EU) 2024/2977, Annex, as replaced by Implementing Regulation (EU) 2026/1731; German Money Laundering Act, §§ 11(4), point 2, and 12(2).)
The corporate record must include the legal name and form, register number where available, registered or principal-office address and the prescribed representative information. Verification uses an official register extract, constitutive or equivalently probative documents, or the institution's own documented register examination. The institution must also establish the presenter's authority to open this account. A mandate limited to another transaction, a joint-signature requirement or revoked authority can prevent acceptance of that presenter acting alone. These are applications of the authority check, not a universal additional document list. (German Money Laundering Act, §§ 10(1), point 1, 11(4), point 2, and 12(2).)
For a new relationship with an association or arrangement covered by §§ 20–21, the institution must obtain registration proof or a transparency-register extract. It must collect beneficial-owner information through the customer or the person acting for the customer under § 11(5). Register inspection can suffice for verification where that information matches and the specified doubts or higher-risk indications are absent. A mismatch, doubt about identity or ownership, or relevant higher risk requires further work. The register step therefore supplements the collection process and can satisfy the verification step only on its statutory conditions. (German Money Laundering Act, §§ 3, 11(5) and 12(3).)
The institution must also assess the business purpose, expected activity and politically exposed person risks. Source of funds concerns the origin of money involved in the relationship or transaction. Source of wealth concerns how a person accumulated wealth. The required checks depend on applicable duties and risk, including enhanced measures for specified higher-risk situations. A company-registration credential does not answer either funding question. Corporate release should follow a tested ownership, mandate and enhanced-review process, with separate evidence requests. (Directive (EU) 2015/849, Articles 13, 18–20; German Money Laundering Act, §§ 10 and 15.)
Ordinary ongoing monitoring considers the source of assets where necessary. Higher-risk and politically exposed person cases attract the specified enhanced measures, including establishing the source of assets, senior-management approval and enhanced monitoring. Listed high-risk-country cases carry further information requirements concerning the customer, beneficial owner, funds and wealth. Complex or unusually large transactions, unusual patterns and transactions without an apparent economic or lawful purpose require the inquiry prescribed by § 15(6). These triggers determine the additional evidence; a wallet presentation does not establish the answers. (German Money Laundering Act, §§ 10(1), point 5, and 15(2)–(6).)
The variant choice changes who collects that evidence, rather than what the institution must establish. Under A, the representative presents the relevant credentials into the institution's business-onboarding process. Under B, supplied evidence must follow the selected own-verification, reliance or contracted-performance route. If the institution obtains a fresh presentation, it can collect the relevant company and representative evidence directly. Under C, the vendor can perform assigned checks, but must distinguish the representative, company and beneficial owners in its records. The UAE app needs no unrestricted ownership chart or funding dossier merely because it initiated the application. Separate recipient purposes, storage restrictions and transfer conditions apply to those materials. (German Money Laundering Act, §§ 8, 10–12 and 17; Regulation (EU) 2016/679, Articles 5–6 and 44–46; Regulation (EU) No 910/2014, Article 5b(10).)
Applicable financial-sanctions restrictions also require separate controls for consumers and companies. A genuine identity credential does not establish that opening the account or making funds available is permitted. The institution must check the applicable restrictions and maintain the required controls as listings and customer circumstances change. (Deutsche Bundesbank, Häufig gestellte Fragen zum Thema Finanzsanktionen, June 2026, sections A.1 and A.3.)
Variant A makes the account provider the relying party
Variant A is the preferred starting structure because the institution requests identity evidence for its own regulated account. The German institution registers in its qualifying Member State establishment and uses its own relying-party identity. Its financial authorisation and wallet registration remain separate requirements. The customer contracts with that institution for the account, even when the UAE brand appears throughout the app. App terms should identify any separate technology service without suggesting that the UAE company issues the electronic money or supplies the account. (Regulation (EU) No 910/2014, Article 5b(1)–(2); Implementing Regulation (EU) 2025/848, Article 3; Directive (EU) 2015/2366, Articles 51–52.)
The proposed customer sequence begins when the app sends the customer into an institution-controlled onboarding session. The institution creates the identity request for that session, authenticates as the relying party and explains the requested attributes. The wallet displays the requesting institution and the disclosure for the user's approval. The response goes to the institution's verifier. The institution completes the remaining due diligence, deals with missing evidence and decides whether to open the account. Its legal name should remain visible through this sequence, including the account terms and complaint contact. (Regulation (EU) No 910/2014, Article 5b(2), (8)–(9); German Money Laundering Act, §§ 10–13; Directive (EU) 2015/2366, Articles 52 and 101.)
The ordinary identity request contains the given names, surname, birthplace, date of birth, nationality and residential-address evidence required for the approved German process. A field that contains only a contact address needs further treatment. The verifier also receives the necessary issuer, signature, session and status evidence. National identifiers, portraits, unrelated attestations and a complete wallet inventory are outside the proposed default request. The institution can collect contact information separately for account communications. Each additional field needs a stated evidential or service purpose. (German Money Laundering Act, § 11(4), point 1; Regulation (EU) 2016/679, Articles 5–6 and 87; Implementing Regulation (EU) 2024/2977, Annex.)
The institution can run verification software itself or instruct a contractor. It must retain control of the permitted method, required checks, exceptions and evidence requirements. A contractor's role is determined by what it performs: hosting a software component differs from carrying out the institution's identification measures or intermediating a wallet transaction. The applicable § 17 and intermediary conditions follow that classification. Outsourced execution must still produce an attributable record that the institution can inspect and explain to its supervisor. (German Money Laundering Act, §§ 8 and 17; Regulation (EU) No 910/2014, Article 5b(9)–(10); EBA Guidelines EBA/GL/2022/15, paragraphs 46–49.)
The UAE app receives a limited result only after the purpose and transfer conditions for that disclosure are met. The proposed callback contains an opaque transaction reference, the minimum completion or next-action status, issue and expiry times, and the intended recipient. The institution authenticates the response and retains its internal mapping to the evidence. The app reference must not confer a right to retrieve the underlying file. A pending-review status can direct the customer back to the institution without disclosing a screening match. The app does not need the underlying names, address, portrait, sanctions analysis or source-of-funds documents merely to continue navigation. A result linked to an app user remains personal data despite the opaque reference. (Regulation (EU) 2016/679, Articles 4(1), 5–6, 25 and 44–46; German Money Laundering Act, § 47.)
Before that transfer condition is satisfied, the institution can display the decision directly to the customer in its own controlled segment. A system-browser handoff is a proposed way to prevent app code reading that segment. The separation must also cover URLs, callbacks, analytics SDKs, crash logs and support tools. This interim arrangement supplies an institution-controlled account experience; the complete branded integration follows only when its linked data flows are lawful. Removing the raw credential from a callback does not authorise the remaining customer-linked information. (Regulation (EU) 2016/679, Articles 5, 25, 32 and 44–46; EDPB Guidelines 05/2021, version 2.0, section 2.)
The institution and UAE company need an agreement that identifies the app function, permitted result fields, recipients and processing locations. It should prohibit additional payload collection through telemetry and require approval for changes affecting the institution's identification process. Any processor schedule must reflect actual instructions; independent app purposes require their own controller analysis. The verification contract should address evidence delivery, service availability, subcontractors, incident assistance, access for the institution and supervisor, and exit. These are proposed contract controls implementing the applicable outsourcing, data and ICT duties. (Regulation (EU) 2016/679, Articles 26 and 28; German Payment Services Supervision Act, § 26; Regulation (EU) 2022/2554, Articles 28 and 30.)
The institution decides when a replacement presentation or another identification method is needed. It maintains the compliance record and assesses the effect of expiry, incorrect address data or a compromised wallet. A verifier alerts the institution to relevant failures and performs the agreed status checks. The UAE company receives only the action information required for its task and must correct or delete its own records where applicable. Credential revocation does not instruct the app to erase the institution's legally retained evidence or close the customer's account. (German Money Laundering Act, §§ 8, 10 and 11; Regulation (EU) 2016/679, Articles 16–19; Implementing Regulations (EU) 2024/2977, Article 5, and 2024/2979, Articles 6–7.)
The customer contacts the institution about the account, onboarding rejection and financial complaints. The UAE company answers for its app service and its own personal-data processing. The wallet provider handles recovery and wallet-function problems; a vendor can provide technical support within those allocations. A shared helpdesk can route a complaint, but the institution must retain a usable escalation path and comply with the applicable response obligations. (Directive (EU) 2015/2366, Article 101; Regulation (EU) No 910/2014, Article 5a(10); Regulation (EU) 2016/679, Articles 13–14, 26(3) and 77.)
The practical advantage of A is the shorter evidence chain between the identity presentation and the party responsible for the account. It also reduces the justification needed for additional recipients of the identity file. The cost is reduced UAE control over the regulated segment, plus dependence on the institution's verification capability and approval process. A does not remove the transfer problem for a linked result or the institution's duty to use a lawful identification method. Those conditions determine when this proposed first release can operate. (German Money Laundering Act, §§ 12–13 and 17; Regulation (EU) 2016/679, Articles 5 and 44–46.)
Variant B gives the foreign group its own relying party role
Variant B can be used only through a registration route available to the entity that actually requests the credentials. Article 5b ties registration to Member State establishment, without making EU ownership a condition. A UAE company with no qualifying EU establishment cannot infer a production entitlement from its EU customers or foreign participation in a sandbox. A branch and a subsidiary require different legal descriptions. The institution remains the customer's account provider in either structure. (Regulation (EU) No 910/2014, Article 5b(1)–(2); Implementing Regulation (EU) 2025/848, Article 3 and Annex I, points 1–4.)
An accepted EU branch would be an establishment of the UAE legal person, subject to the applicable national registration policy. The request would need to identify that actual legal person and its registered establishment. A separately incorporated EU subsidiary would request in its own name and carry its own relying-party duties. Its parent would not acquire the same registration or data rights through ownership. A GDPR representative or address for service performs a different legal function and cannot substitute for the required establishment. (Implementing Regulation (EU) 2025/848, Articles 3–4 and Annex I; Regulation (EU) 2016/679, Article 27; EDPB Guidelines 3/2018, version 2.1, section 4.)
The customer must understand why this additional company requests identity data when the account belongs to the German institution. If the first company provides a separate identity-dependent app service, its request should state that service and its own necessary attributes. If it carries out the institution's due-diligence task, the notices and contract should identify that task and the institution. If its actual function is to intermediate the institution's wallet transaction, Article 5b(10) applies to that function. Calling the company an independent relying party cannot remove the intermediary's duties. (Regulation (EU) No 910/2014, Article 5b(2), (8)–(10); Regulation (EU) 2016/679, Articles 4(7)–(8), 13–14 and 28.)
The proposed B sequence begins with that entity's authenticated, declared request and the user's approval. Its verifier checks the presentation and produces the agreed evidence. The institution then receives an evidence package or obtains its own presentation, performs the remaining customer due diligence and makes the account decision. The account terms must still name the institution. An extra wallet approval is required where the chosen protocol and evidence route require another presentation; the design cannot promise that one approval always serves two relying parties. (Regulation (EU) No 910/2014, Article 5b(8)–(9); German Money Laundering Act, §§ 10–13 and 17; Implementing Regulation (EU) 2024/2982, Articles 3–5.)
The evidence route must be selected before implementation. The institution can obtain a fresh presentation addressed to itself; that part of the transaction then uses A's direct-evidence structure. It can also perform its own lawful verification using suitable supplied source evidence, where its approved method permits that evidence and its provenance can be established. The first presentation must not be replayed as if the wallet created a new presentation for the institution. Extracted name and address fields alone do not demonstrate the original signature, holder binding, session or status checks. (Regulation (EU) No 910/2014, Article 5b(9); German Money Laundering Act, §§ 8, 12–13; Implementing Regulation (EU) 2024/2982, Articles 3–5.)
Statutory third-party reliance is a further route for a supplier in an eligible obliged or supervised category. A third-country supplier must meet the prescribed equivalent due-diligence, retention and supervisory conditions. The listed-high-risk-country restriction and its specified exceptions also apply. Wallet registration, an EU subsidiary or two contracts do not establish that eligibility. For customers resident in Germany, the third party must comply with the German identification rules. Necessary information must reach the institution without delay and directly, with the prescribed access to prompt supporting copies. (German Money Laundering Act, § 17(1)–(3); Directive (EU) 2015/849, Articles 25–28.)
A proposal to reuse the supplier's previous identification must meet § 17(3a). The supplier must have identified the person for its own business relationship without simplified due diligence. The compliant identification or update must have been completed within 24 months, with no relevant doubts and no expired identification document where one was used. These conditions govern reuse of earlier information; they do not impose a 24-month history on a fresh identification. The group rule in § 17(4) requires the supplier to belong to the same group as the relying institution, qualifying group controls and effective supervisory oversight. A UAE parent and its EU subsidiary do not satisfy that rule merely by belonging to their own group while using an external German institution. (German Money Laundering Act, § 17(3a)–(4).)
Contracted performance under § 17(5) is separately available for suitable contractors, with reliability assessment, supervision and sample checks under § 17(6)–(7). The information-delivery conditions also apply. Both the reliance and contracted-performance provisions concern the measures in § 10(1), points 1–4; they do not themselves delegate the entire ongoing-monitoring duty in point 5. B therefore needs a defined arrangement where another party performs those measures. The institution's own verification and purely technical evidence transport should be classified according to what actually occurs. (German Money Laundering Act, § 17(1), (3) and (5)–(7); Directive (EU) 2015/849, Articles 25–29.)
The additional recipient's data entitlement follows its actual purpose. A company performing identification for the institution can process the identity categories and verification evidence necessary for that instructed task. A company supplying its own app service must justify each attribute for that service. It cannot adopt the institution's entire AML dataset merely because that dataset is useful for a customer profile. On the stated technology-app facts, the smaller completion result remains the starting point for the app's own needs. A broader collection requires a different, substantiated purpose or delegated task. (Regulation (EU) 2016/679, Articles 5–6 and 28; German Money Laundering Act, § 11a; Regulation (EU) No 910/2014, Article 5b(3)–(4).)
A genuine direct presentation by the individual to a UAE controller is not a Chapter V transfer for that initial act if no controller or processor discloses or makes the data available. The UAE controller's relevant EU-facing processing can still fall within GDPR Article 3(2). This distinction supplies neither wallet-registration eligibility nor a right to reuse the data. A later disclosure to another non-EEA company can trigger Chapter V. Delivery from the UAE to the German institution is not a disclosure to a third country for that chapter, though UAE outbound-transfer requirements may apply. An institution-directed disclosure remains subject to its own analysis even when the user's device carries it. (Regulation (EU) 2016/679, Articles 3 and 44–46; EDPB Guidelines 05/2021, version 2.0, paragraph 9 and sections 2.2 and 4; UAE Federal Decree-Law No. 45 of 2021, Articles 22–23.)
An accepted EU branch is part of the UAE legal person. Processing in the context of that establishment can fall within Article 3(1), including processing in Dubai. Internal access within the same controller or processor can fall outside Chapter V because no separate controller or processor receives a disclosure. The other GDPR duties and risks of processing abroad remain. This does not make an external institution's disclosure internal. If that institution grants the UAE company access to its data from Dubai, it must assess that separate disclosure and the receiving establishment. (Regulation (EU) 2016/679, Articles 3(1), 5 and 32; EDPB Guidelines 3/2018, section 1(c); EDPB Guidelines 05/2021, sections 2.2 and 4.)
A separately incorporated EU subsidiary and the UAE parent are different legal persons. The subsidiary's EEA-to-EEA delivery to the institution differs from disclosure or support access to its parent in Dubai. The latter can trigger Chapter V despite common ownership. Incorporation produces an effective EEA evidence boundary only if access, keys, support, logs and retention follow that allocation. The actual recipient and instructions govern; a device or routing label cannot convert an institution's disclosure into an independent act by the individual. (Regulation (EU) 2016/679, Articles 3 and 44–46; EDPB Guidelines 05/2021, sections 2.2 and 4.)
The institution should contract directly for access to the evidence on which its account decision depends. The agreement should specify accepted issuers and methods, evidence delivery, record integrity, status checking, changes to verification logic and correction notices. It should allocate responsibility when a request exceeded its declared scope or the evidence did not meet the agreed method. Audit and regulatory access must reach the relevant subcontractors and records. A private indemnity can allocate financial consequences between the parties, but cannot transfer the institution's statutory AML responsibility. (German Money Laundering Act, §§ 8 and 17; German Payment Services Supervision Act, § 26; Regulation (EU) 2022/2554, Articles 28 and 30.)
Retention requires two separate decisions. The institution retains the records required for its account and due-diligence duties. The first relying party retains only what its own lawful purpose permits, or processes records under documented instructions for the institution. If it acts as a wallet intermediary, it must comply with the transaction-content storage prohibition. Its registration certificate does not authorise an indefinite reusable KYC archive. A separate controller's duty to correct data, or an intermediary's duty to avoid content storage, must remain effective after the institution opens the account. (Regulation (EU) No 910/2014, Article 5b(10); German Money Laundering Act, § 8; Regulation (EU) 2016/679, Articles 5, 16–19 and 28.)
Refresh and incidents now involve an additional accountable party. The first relying party must maintain its registration information and credentials, while the institution decides the effect on its customers. The contract should require prompt notification of relevant compromise, invalid verification and corrected attributes. Withdrawal of the first party's access credentials should stop new requests through that route and trigger a fallback, with the institution retaining its evidence and decision history. Customers need the first party's privacy and service contact as well as the institution's financial-complaint route. Each controller remains answerable for the processing it determines. (Implementing Regulation (EU) 2025/848, Articles 6 and 9; Regulation (EU) 2016/679, Articles 13–14, 19 and 33–34; Directive (EU) 2015/2366, Article 101.)
B can be justified where the group operates a defined identity-dependent service or a properly contracted verification function that warrants the additional role. Its commercial attraction is greater control over that function and the possibility of supporting several institution relationships. Each receiving institution still needs usable evidence and a lawful route, and each additional disclosure needs its own justification. On the stated facts, the added establishment, disclosure and evidential obligations make B a later option rather than the shortest first deployment. That preference changes only when a real service requirement outweighs those additional obligations. (Regulation (EU) No 910/2014, Article 5b; German Money Laundering Act, § 17; Regulation (EU) 2016/679, Articles 5–6 and 44–46.)
Variant C uses an identity vendor for the two organisations
Variant C is workable when the vendor's actual function is defined before its services are described as verification for both clients. A supplier does not become a relying party merely by selling software. Hosting, support access and diagnostic processing can still give it personal-data duties even if the product is described as software. An instructed verification processor has GDPR duties for the processing it performs. A vendor that intermediates wallet transactions is deemed a relying party under Article 5b(10), even if its commercial contract calls it a processor. The parties must assess these classifications together. (Regulation (EU) No 910/2014, Article 5b(9)–(10); Regulation (EU) 2016/679, Articles 4(8) and 28.)
The proposed first C configuration supports A. The institution is the underlying relying party and the vendor verifies the institution-directed presentation. The vendor writes the necessary evidence into the institution's controlled repository. The app receives only the justified result after the transfer condition is satisfied. The vendor can supply integration and support services to the UAE company without giving it the institution's identity file. This arrangement serves two commercial clients while keeping the identity-verification purpose with the institution. (German Money Laundering Act, §§ 8 and 17; Regulation (EU) 2016/679, Articles 5, 28 and 44–46.)
A vendor performing the institution's identification measures must meet the relevant contracted-performance requirements. If the institution relies on the vendor's own earlier due diligence, the eligibility and reuse conditions explained for B apply. A shared supplier and two commercial contracts do not establish statutory reliance. A supplier that only provides software requires a different classification from a contractor that carries out the identification measures. (German Money Laundering Act, § 17(1)–(7).)
If the vendor actually verifies credentials for two separate relying parties, both purposes and recipient roles must be represented lawfully. The institution's account-identification purpose and the other party's separate purpose require distinct necessity assessments. The relevant underlying relying parties and intermediary associations must be registered and reflected in the applicable certificates and requests. A vendor registration does not give an undisclosed subscriber unrestricted access to wallet attributes. Where the supported protocol cannot express the proposed recipients and disclosures properly, the service must use separate presentations or narrow the recipients. (Regulation (EU) No 910/2014, Article 5b(2)–(4), (8) and (10); Implementing Regulation (EU) 2025/848, Annex I, point 16, and Annex IV, as amended by Implementing Regulation (EU) 2026/1730; Regulation (EU) 2016/679, Articles 5–6 and 13–14.)
The Commission's Architecture and Reference Framework describes the concrete intermediary request. The vendor uses its own access certificate containing the served relying-party association, together with that client's registration certificate. The vendor and each underlying relying party register through their respective qualifying establishments. A client using only the intermediary need not have a separate direct-access certificate under that architecture. The vendor must manage the required client and instance associations. This implementation gives effect to the registered relationship; it does not allow an unregistered UAE-only client to borrow the vendor's eligibility. The statutory application dates for registration-certificate checks still govern. (Implementing Regulation (EU) 2025/848, Annex I, point 16, and Annex IV, point 3(k), as amended by Implementing Regulation (EU) 2026/1730; European Digital Identity Wallet Architecture and Reference Framework, version 3.0.0, section 6.6.5; Implementing Regulation (EU) 2024/2982, Article 8.)
The customer sequence should disclose the underlying account provider, the vendor's function and any other intended recipient before the presentation. The wallet request must use the identity and associations required by the applicable intermediary arrangement. The vendor receives the permitted presentation, performs the specified checks and delivers purpose-specific outputs to the authorised destinations. The institution then completes its due diligence and decides whether to open the account. The customer's account contract remains with the institution; a vendor's verification terms cannot replace that contract or the institution's duties. (Regulation (EU) No 910/2014, Article 5b(8)–(10); Implementing Regulation (EU) 2025/848, Articles 7–8 and Annex IV; German Money Laundering Act, §§ 10 and 17.)
The vendor may process the identity and residential-address evidence needed to execute the institution's verification task. It should return the values and decision-time evidence necessary for that institution's method. For the UAE app, it should return only the fields justified by the app's own purpose or documented instructed task. A single commercial order for two outputs cannot establish two lawful data entitlements. If the app only needs a completion signal, the vendor should not produce a second identity dossier for it. (Regulation (EU) 2016/679, Articles 5–6 and 28; German Money Laundering Act, §§ 8 and 11a.)
An intermediary may not store data about the content of the wallet transaction. The proposed arrangement therefore performs transient verification and delivers the required evidence directly into an institution-controlled repository. It must distinguish that institutional record from the vendor's own retained transaction-content copy. Diagnostic logs, support attachments, backups and a shared customer vault must respect the same prohibition. The Architecture and Reference Framework requires deletion immediately after forwarding, or after the necessary checks if nothing is forwarded. Outsourcing or AML retention language does not authorise the intermediary to disregard Article 5b(10). If a proposed storage service requires the vendor to retain that content in its intermediary function, this design must be changed before use. (Regulation (EU) No 910/2014, Article 5b(10); European Digital Identity Wallet Architecture and Reference Framework, section 6.6.5; German Money Laundering Act, §§ 8 and 17; Regulation (EU) 2016/679, Articles 5 and 28.)
A vendor that determines a separate reusable identity-product purpose needs a different controller and service analysis. It must justify its collection, retention, disclosures and later uses for that purpose. If its conduct also constitutes wallet intermediation, the specific content-storage prohibition still requires compliance. The proposed launch excludes a common KYC vault, cross-client enrichment and training a general model on wallet or AML material. A software capability to reuse a credential is not permission to process it for every customer of the vendor. (Regulation (EU) 2016/679, Articles 4(7), 5–6 and 26; Regulation (EU) No 910/2014, Article 5b(10); Directive (EU) 2015/849, Article 41(2).)
The recommended initial verifier has an EU establishment and keeps processing and support access within the EEA. A later non-EEA support team, subprocessor or app recipient requires its own role and transfer assessment before access. The vendor must enforce the destination and purpose of each output, separate client environments and prevent shared identifiers entering unrelated analytics. The institution should test those controls through the actual support and logging paths, because an EU server location alone does not keep the data within the EEA. (Regulation (EU) 2016/679, Articles 25, 28, 32 and 44–46; EDPB Guidelines 05/2021, version 2.0, section 2.)
The institution should have enforceable rights to the vendor's relevant records, tests, personnel assistance and subcontracting information. The contract should identify who approves issuer support and method changes, who handles status-service failure, and how the institution replaces the vendor. Where the service supports a critical or important function, the additional DORA contract and exit requirements apply. Commercial confidentiality cannot make the evidence unavailable to the institution or its competent authorities. A contract promising only a vendor score would leave the institution unable to demonstrate the underlying verification. (German Payment Services Supervision Act, § 26; Regulation (EU) 2022/2554, Articles 28 and 30; German Money Laundering Act, §§ 8 and 17.)
The vendor should send relevant incident and correction information to each affected controller through agreed channels. It can execute credential-status checks, but the institution sets the consequences for account acceptance and existing customers. Compromise of the intermediary's credentials can interrupt every client using that route, so recovery and a lawful alternative method must be tested. The financial complaint remains with the institution. Privacy complaints follow the actual controller allocation, while the vendor's helpdesk can handle technical faults and route other complaints. (Regulation (EU) 2016/679, Articles 19, 28 and 33–34; Implementing Regulation (EU) 2025/848, Article 9; Directive (EU) 2015/2366, Article 101.)
C can reduce duplicate integration work and concentrate specialist verification skills in a supplier. It also adds dependence on the supplier's availability, subcontractors and evidence delivery. Its value depends on the institution being able to supervise and replace that supplier. The preferred initial use combines A's institution-led request with C's narrowly instructed technical service. A genuinely shared verification service for two relying parties requires the additional recipient, registration, purpose and storage conditions for that two-recipient service. (Regulation (EU) 2022/2554, Articles 28 and 30; Regulation (EU) No 910/2014, Article 5b(10); Regulation (EU) 2016/679, Articles 5 and 28.)
The variant choice follows the service need and evidence chain
All three arrangements keep the regulated account contract with the institution. The main legal difference is which additional company requests or handles identity evidence before that institution uses it. In A, the institution can receive the original directed presentation. In B, the foreign group needs an available establishment and registration route plus a lawful reason to perform its additional task. C adds a supplier whose actual processing and intermediary functions determine its duties. None reduces the institution's ultimate responsibility for the applicable customer due diligence. (Regulation (EU) No 910/2014, Article 5b; German Money Laundering Act, § 17; Directive (EU) 2015/849, Articles 25–29.)
The strongest argument for B is control over an identity service used across several institution relationships. The strongest argument for C is an accepted verifier that the institution would otherwise have to build and maintain. Those benefits require usable evidence and lawful access for the intended recipients. The preference for A follows from the stated app role: the institution needs the full identification evidence, while the app mainly needs navigation and account-service outputs. Giving the app a second identity file adds duties without establishing an additional necessity on those facts. (Regulation (EU) 2016/679, Articles 5–6; German Money Laundering Act, §§ 8, 11a and 17.)
The parties should choose the data boundary before choosing a vendor product. A's proposed separation fails if the institution's name conceals an undeclared UAE requester or unapproved access to identity data. B cannot use a subsidiary as a registration label while leaving the actual requester undisclosed. C cannot use a processor label to conceal an independent purpose or intermediary storage. The declared arrangement, executable request, delivery destination, contract and production logs must describe the same service. Where they differ, the affected flow must be corrected before release. (Regulation (EU) No 910/2014, Article 5b(2)–(4), (8) and (10); Regulation (EU) 2016/679, Articles 5(2), 25–26 and 28.)
Each processing purpose has its own controller and legal basis
The institution is controller for its statutory customer due diligence and account operation. Necessary AML processing ordinarily uses GDPR Article 6(1)(c), read with the applicable legal duty. Objectively necessary account-contract processing can use Article 6(1)(b). Defined fraud-prevention processing requires its own assessment of a specific legal obligation or a documented legitimate-interest, necessity and balancing assessment. Those grounds do not authorise unrestricted collection of the wallet payload. (Regulation (EU) 2016/679, Articles 4(7), 5 and 6; German Money Laundering Act, § 11a.)
Article 6(1)(b) concerns processing objectively necessary for the contract with the individual. The institution's commercial agreement with the UAE company does not establish that basis for an additional identity archive. The app must identify its own necessary customer-contract purpose or another lawful basis. Article 6(1)(c), read with Article 6(3), requires the relevant obligation to arise under Union or Member State law. A foreign legal duty or the institution's AML responsibility is not automatically that basis for the UAE company's own processing. (Regulation (EU) 2016/679, Article 6(1)(b)–(c) and (3); EDPB Guidelines 2/2019, paragraphs 23–33.)
The UAE company is controller for the app analytics and other purposes it chooses. If the parties jointly determine the purpose and essential means of a collection operation, Article 26 applies to that operation. The UAE company need not receive raw data to exercise that control. Branding alone is not decisive; deciding mandatory identity fields, recipients or linked conversion events can be. A processor role under Article 28 is available only for functions carried out on documented instructions without an independent purpose. (Regulation (EU) 2016/679, Articles 4(7)–(8), 26 and 28; EDPB Guidelines 07/2020, version 2.1, paragraphs 39–46, 51–56 and 69.)
Wallet-user approval authorises the particular presentation under the wallet process. It does not replace the institution's statutory basis, consent for optional analytics, a biometric condition or international-transfer safeguards. The parties should provide purpose-specific notices before collection. Optional terminal storage or access must also satisfy Germany's TDDDG § 25, including consent unless a statutory exception applies. Describing every analytics event as necessary for onboarding would not establish that exception. (Regulation (EU) 2016/679, Articles 6–7, 9 and 13–14; German Telecommunications Digital Services Data Protection Act, § 25.)
These distinctions should be visible in the customer experience. The wallet approval identifies the proposed disclosure. The institution's privacy notice explains its account and AML processing, including applicable retention. The proposed optional app analytics use a separate consent that identifies their purpose and satisfies the applicable consent conditions. Other analytics need their own basis and any required terminal-access permission. Refusing optional analytics should not prevent a customer from using the regulated onboarding service. Withdrawal of a consent does not erase a record that the institution must retain under a separate legal duty. (Regulation (EU) 2016/679, Articles 6–7, 13 and 17(3)(b); German Money Laundering Act, §§ 8 and 11a; EDPB Guidelines 05/2020, paragraphs 25–41 and 114–120.)
Fraud prevention also needs an identified decision-maker and purpose. The institution may instruct a vendor to detect altered evidence as part of its verification process. The UAE app's separate device-abuse or account-security checks require a basis for that app purpose and only the necessary data. If the companies jointly determine a shared fraud operation, they must address joint control for that operation. Reusing the same vendor does not itself create joint control, and describing every fraud feature as AML does not supply the app with the institution's legal-duty basis. (Regulation (EU) 2016/679, Articles 4(7), 5–6, 26 and 28; EDPB Guidelines 07/2020, version 2.1, paragraphs 50–56.)
The launch should exclude wallet and AML data from commercial analytics and model training. AML-purpose restrictions apply alongside GDPR's purpose and minimisation rules. Truly anonymous aggregate reporting may support app analysis, but creating those aggregates can still involve personal-data processing under the UAE company's control. Stable pseudonyms, linked approval events and small identifiable cohorts remain personal data. A later fraud-model proposal requires its own lawful-purpose, necessity and special-category assessment. (Directive (EU) 2015/849, Article 41(2); German Money Laundering Act, § 11a(1) and (3); Regulation (EU) 2016/679, recital 26 and Articles 5, 9 and 35.)
The institution must assess Article 22 where a solely automated onboarding decision has legal or similarly significant effects. Article 22(2) requires contractual necessity, authorisation by applicable Union or Member State law with safeguards, or the person's explicit consent. The ordinary AML processing basis and wallet approval do not themselves establish an exception. Where Article 22(3) applies, safeguards include human intervention, an opportunity to express a view and the ability to contest the decision. The reviewer must have the authority and capability to consider relevant evidence and change the outcome. Routine approval of a machine result does not provide that review. A decision based on special-category data also needs an Article 9(2)(a) or (g) condition and suitable safeguards under Article 22(4). (Regulation (EU) 2016/679, Article 22(1)–(4); Article 29 Working Party Guidelines WP251rev.01, pages 20–24 and 27, endorsed by the EDPB.)
A UAE result needs a valid transfer route
An institution or EU vendor making a linked onboarding result available to the separate UAE company transfers personal data to a third country. EU hosting does not avoid that consequence if UAE staff, support systems or software services can access the information. The same applies to a short “approved” response linked to an app user. The Commission's adequacy decisions do not cover the UAE. (Regulation (EU) 2016/679, Articles 4(1) and 44–46; EDPB Guidelines 05/2021, version 2.0, section 2; European Commission, “Data protection adequacy for non-EU countries”.)
The transfer instrument must fit the importer. The 2021 transfer standard contractual clauses cover importers whose relevant processing is not already subject to GDPR. This UAE company's deliberate service offering to people in the EU can bring the relevant processing within Article 3(2). The parties therefore cannot assume that signing a standard controller-to-controller or controller-to-processor module solves the transfer. Changing the contractual role label does not change the territorial test. For regular processing under Article 3(2), the UAE company must appoint an EU representative in writing unless Article 27(2)'s narrow exception applies. Users must receive the relevant contact details. (Commission Implementing Decision (EU) 2021/914, Article 1(1); Regulation (EU) 2016/679, Articles 3(2), 13(1)(a), 14(1)(a) and 27; EDPB Guidelines 3/2018, section 2(d); European Commission, SCC Questions and Answers, question 24.)
The Commission's published guidance describes additional clauses for importers already subject to GDPR as being developed. That guidance does not extend the adopted 2021 modules to those processing operations. The parties need an available instrument that actually covers the transfer and the importer. Adding GDPR language to an out-of-scope module does not turn it into a pre-approved transfer mechanism. (Commission Implementing Decision (EU) 2021/914, Article 1(1); European Commission, SCC Questions and Answers, question 24.)
Processing within the same legal person through its employee or branch can have a different Chapter V analysis. Applicable GDPR safeguards still govern that processing. Disclosure to a separate group company must be assessed for a transfer. A branch does not by itself resolve whether the German institution makes data available to a recipient in a third country. (EDPB Guidelines 05/2021, sections 2.2 and 4.)
Before enabling the callback, the parties must have an applicable Article 46 mechanism with any required approval. Contractual clauses under Article 46(3)(a) are one possible route, but require the competent supervisory authority's actual authorisation. The draft authorisation is subject to the Article 64(1)(e) consistency process. Drafting or signing the contract does not complete that process. Approved binding corporate rules work only for a qualifying group and covered transfers. The parties must also assess destination-country law, public-authority access, onward recipients and effective supplementary safeguards. Encryption alone does not solve a transfer where the importer needs plaintext and cannot provide the required protection. (Regulation (EU) 2016/679, Articles 46–47 and 64(1)(e); EDPB Recommendations 01/2020, version 2.0, Annex 2, Use Cases 1, 2, 6 and 7.)
The EDPB approved Europrivacy transfer-certification criteria in April 2026. That scheme excludes importers whose relevant processing is already subject to GDPR Article 3 and excludes joint controllership. It therefore cannot solve this UAE recipient's transfer if its processing falls within those exclusions. Even for an eligible importer, approval of the scheme is not a certificate for the company. A valid certificate covering the processing and binding, enforceable commitments must be in place before the transfer. (Regulation (EU) 2016/679, Articles 42 and 46(2)(f); EDPB Opinion 15/2026, paragraphs 12–13, 25, 27, 32, 34 and 48–54.)
A routine partner-to-UAE pipeline should not depend on a general wallet-consent screen. Article 49 derogations have specific, restrictive conditions; its contract routes do not support planned, stable transfers merely because the app terms mention them. Direct collection from a person by a foreign service and disclosure by the institution are legally different situations. Routing the institution's intended callback through the person's device does not by itself turn that disclosure into independent user collection. (Regulation (EU) 2016/679, Article 49; EDPB Guidelines 2/2018, sections 1 and 2.1–2.2; EDPB Guidelines 05/2021, section 2.2.)
Retention and refresh follow the account relationship
The institution must retain the identification and due-diligence records required by German law. The ordinary five-year period runs from the end of the calendar year in which the business relationship ends, subject to longer statutory retention duties. Section 8(4) also requires destruction of those records no later than ten years after the applicable period starts. A wallet's expiry does not erase the retention duty. The relying-party registrar's ten-year registration-record rule concerns a different record and does not authorise the app to keep customer credentials for ten years. (German Money Laundering Act, § 8(4); Implementing Regulation (EU) 2025/848, Article 10; Regulation (EU) 2016/679, Articles 5(1)(e) and 17(3)(b).)
A processor's service-end obligations require return or deletion of personal data, at the controller's choice, and deletion of copies unless applicable Union or Member State law requires storage. The agreement must distinguish this process from records lawfully retained for the institution's continuing duties. It cannot grant the vendor a separate indefinite archive. A wallet intermediary remains subject to the stricter transaction-content prohibition during its service. (Regulation (EU) 2016/679, Article 28(3)(g); Regulation (EU) No 910/2014, Article 5b(10).)
The institution should define when a new presentation is required: expiry, conflicting information, changed address, doubts about the original identification or a relevant compromise notice. It must use the applicable credential and wallet-unit status mechanisms. A valid presentation does not promise that an issuer will push every later address change to the account provider. The customer must approve a new disclosure where the wallet process requires it. (German Money Laundering Act, §§ 10(1), point 5, and 11(3); Implementing Regulations (EU) 2024/2977, Article 5, and 2024/2979, Articles 6–7; German EUDI Wallet programme, FAQ.)
Revocation needs a reason-sensitive response. Credential expiry, a compromised wallet unit and withdrawal of a wallet solution are different events. The institution should stop accepting affected evidence, assess impacted decisions and obtain replacement identification where necessary. It should preserve the lawful historical record and assess the account risk before deciding on restrictions or closure. Correct inaccurate current records and notify recipients where GDPR Article 19 requires it, while retaining the dated evidence of the earlier decision. Loss of the user's wallet should also activate an accessible recovery or alternative-identification route. (Regulation (EU) No 910/2014, Articles 5a(15), 5c and 5e; Implementing Regulation (EU) 2025/847, Articles 3–5; German Money Laundering Act, §§ 10–11; Regulation (EU) 2016/679, Articles 16 and 19.)
Contracts must preserve supervision and clear complaint routes
Where the app or verifier performs outsourced activities, the agreement must preserve the information, control and examination rights required by German payment law. Those rights must remain effective abroad and reach the relevant subcontractors and records. For material outsourcing to a third-country company, the contract must provide an agent in Germany for service of supervisory documents. That procedural agent has a different function from an establishment for wallet registration or a GDPR representative. An unrelated commercial contract does not attract these duties merely because its counterparty operates the app. (German Payment Services Supervision Act, § 26(1).)
DORA requires the institution to manage ICT third-party risk and remain responsible for compliance. Its contracts must address the services, processing locations, data access and return, incident assistance and cooperation with competent authorities. Critical or important functions require additional provisions on audit, monitoring and exit. The EU-subsidiary requirement for designated critical third-country ICT providers does not apply automatically to every UAE software supplier. (Regulation (EU) 2022/2554, Articles 28, 30 and 31(12).)
The institution must record material and non-material outsourcing in its German outsourcing register. It must notify BaFin and the Bundesbank of planned material outsourcing and make the prescribed change notifications. Materiality turns on the consequences of failure for authorisation requirements, other obligations, financial performance, soundness or continuity. DORA separately requires an information register of ICT arrangements and timely notification of planned arrangements supporting critical or important functions. These notices and records must be prepared for the actual allocation of functions; a notification requirement is not automatically a prior-approval requirement. (German Payment Services Supervision Act, § 26(1)–(2) and (4); Regulation (EU) 2022/2554, Article 28(3).)
Incident provisions should identify who suspends wallet requests, revokes access credentials, preserves evidence and informs the institution. Each controller retains its own GDPR notification duties; processors must notify their controller without undue delay. The institution must separately assess financial-sector incident reporting. Vendor confidentiality or foreign-law objections cannot be allowed to defeat the access and cooperation the arrangement requires. (Regulation (EU) 2016/679, Articles 28(3), 33–34; Regulation (EU) 2022/2554, Articles 19 and 30; Implementing Regulation (EU) 2025/848, Article 9.)
The institution must report major ICT-related incidents under DORA. The relevant payment operational and security incidents also fall within its incident provisions for this type of institution. Where an incident affects customers' financial interests within Article 19(3), the institution must inform affected customers without undue delay. Outsourcing the report does not transfer responsibility. Current German law excludes the specified legacy incident obligations for this category, so the reporting process must follow the applicable DORA regime. Internal app and vendor notification deadlines should leave the institution time to meet its own obligations. (Regulation (EU) 2022/2554, Articles 19(1), (3)–(5) and 23; German Payment Services Supervision Act, § 54(7).)
The customer should see the institution's contact for the account, rejected onboarding and financial complaints, together with the applicable dispute-resolution information. The UAE company should identify its app and privacy contact. The wallet provider handles wallet recovery and wallet-function complaints. A vendor helpdesk can assist, but cannot replace these responsible parties. Joint-controller arrangements must preserve the person's ability to exercise rights against each controller. Solely automated decisions with legal or similarly significant effects require the separate Article 22 analysis and applicable safeguards. (Directive (EU) 2015/2366, Articles 52 and 101; Regulation (EU) No 910/2014, Article 5a(10); Regulation (EU) 2016/679, Articles 13–14, 22, 26(3) and 77.)
For complaints within the payment-services scope of § 62, the institution must answer on paper or an agreed durable medium within 15 business days. Exceptional delay for reasons beyond its control requires an interim response stating the reason and final-response date. The final response must arrive within 35 business days. The required dispute-resolution information must be supplied. These deadlines do not automatically govern every app-privacy or wallet-recovery complaint; each complaint follows its applicable regime. App and vendor routing should allow the institution to meet the deadline that applies. (German Payment Services Supervision Act, § 62(1)–(4).)
The wallet dashboard also lets a user request erasure from a relying party and report an allegedly unlawful or suspicious data request to the competent data-protection authority. An erasure request does not itself delete every recipient copy or override lawful AML retention. GDPR also permits a complaint to a supervisory authority in the Member State of habitual residence, work or the alleged infringement. The companies should coordinate their response without requiring the customer to resolve their controller arrangements. A helpdesk cannot replace these public complaint rights. (Regulation (EU) No 910/2014, Article 5a(4)(d)(ii)–(iii); Implementing Regulation (EU) 2024/2982, Articles 6–7; Regulation (EU) 2016/679, Articles 12, 17(3)(b), 26(3) and 77.)
Specified registration misconduct can lead to suspension or cancellation, including inaccurate information or requests outside the registered scope. The registration rules require notification to the relying party and relevant certificate providers without undue delay and within 24 hours, with reasons and available remedies. Affected certificates must be revoked without undue delay as prescribed. The notification limit is not a guaranteed period of continued access. A complaint does not automatically establish a ground for cancellation. Loss of the request route calls for fallback and assessment of affected decisions, with the institution preserving legally required records and separately deciding any account restriction. (Implementing Regulation (EU) 2025/848, Article 9.)
The UAE company's financial activity must remain within its lawful role
Wallet registration does not authorise payment services or electronic-money issuance. The proposed technical role should exclude receiving customer funds, executing payments and issuing the account's electronic money. Payment initiation and account-information services have their own treatment; they are expressly outside PSD2's technical-service exclusion. If the UAE company acts as a payment agent or electronic-money distributor, the institution must use the applicable notification, registration and control arrangements. (Directive (EU) 2015/2366, Articles 3(j), 19–20 and 37; Directive 2009/110/EC, Article 3(4)–(5); German Payment Services Supervision Act, §§ 25 and 32.)
The institution remains the issuer. German law prohibits an electronic-money institution from issuing electronic money through persons acting in its name. Permitted distribution or redemption arrangements must be distinguished from issuance. A contractor that verifies identity does not become a payment agent or distributor merely through that verification task. Any additional financial function needs its own classification and the corresponding institution-controlled arrangements. (German Payment Services Supervision Act, §§ 25 and 31–32; Directive 2009/110/EC, Article 3(4)–(5).)
The UAE activity assessment must also cover the branded customer proposition. CBUAE's published guidance on Federal Decree-Law No. 6 of 2025 identifies arranging, promoting and marketing financial activities as potentially licensed activities. The FAQ explains that providers acting only in a technical capacity remain outside the licensing perimeter unless they themselves conduct, offer, issue or facilitate an Article 61 financial activity, directly or indirectly, or present themselves as doing so. Its additional clarification concerns pure technology supplied exclusively for the benefit of licensed financial institutions. The same FAQ defines that term by reference to CBUAE licensing. An EU-authorised partner therefore does not, by that fact alone, satisfy that specific clarification. The FAQ is general interpretative guidance; the statutory text prevails. The actual conduct and applicable UAE permission must support launch. (CBUAE, “New Law FAQs”, questions 1, 3 and 6, concerning Federal Decree-Law No. 6 of 2025.)
The CBUAE Retail Payment Services and Card Schemes Regulation also excludes specified technical support that does not involve possession of funds, but expressly excepts Payment Initiation Services and Payment Account Information Services from that technical-service exclusion. The UAE firm should document its exact money, instruction and information flows before relying on that exclusion. A contract describing the business as “technology” cannot change the activity actually performed. (CBUAE Retail Payment Services and Card Schemes Regulation, Circular No. 15/2021, Exclusions, paragraph 6 and subparagraphs 6.1–6.4.)
The app's account features therefore need their own activity map. Displaying the institution's account interface, handling customer instructions as its contractor, supplying an independent payment-initiation service and consolidating account information can involve different legal functions. The contract, customer proposition, instruction flow and actual control of funds must support the classification chosen. The technical-services exclusion does not cover an independent payment-initiation or account-information service merely because the app never holds the money. Any agency or distribution role must use the applicable institution-controlled arrangements. (Directive (EU) 2015/2366, Articles 3(j), 19–20 and Annex I, points 7–8; Directive 2009/110/EC, Article 3(4)–(5); German Payment Services Supervision Act, §§ 25 and 32.)
For the assumed mainland company, UAE personal-data law also requires classification of the processing. The federal law reaches a UAE controller or processor handling data about people inside or outside the UAE. Its exclusions for separately regulated banking and credit data and relevant free-zone entities depend on their terms. The fintech label alone does not establish an exclusion. Applicable UAE compliance neither displaces GDPR nor creates EU adequacy. (UAE Federal Decree-Law No. 45 of 2021, Article 2(1)(b) and 2(2)(f)–(g); Regulation (EU) 2016/679, Articles 3 and 44–46.)
Release the service in stages tied to evidence
The first stage should fix the account provider, German adult-customer scope and the UAE company's permitted activity. The institution should approve the lawful identification method, attribute list and exception policy. The parties should map controllers, processors, device access and every recipient, including support and analytics systems. They should document Article 35 screening, complete a data protection impact assessment where required, and complete the financial outsourcing assessment before production. Prior supervisory consultation is required where Article 36's conditions are met. Any unresolved condition that prevents lawful processing or supervision must block the affected flow. (German Money Laundering Act, §§ 10–13 and 17; Regulation (EU) 2016/679, Articles 25, 28 and 35–36; Regulation (EU) 2022/2554, Article 28.)
The next stage should use synthetic identities in the available sandbox. Test valid and expired credentials, revoked status, issuer changes, missing residential addresses, altered audience or session data, vendor outages and user refusal. The evidence package should contain the registered relying-party identity, applicable certificates, accepted issuer and wallet records, approved request schema, test results, retention schedule and contracts. It should also include the decision procedure, incident plan and a worked customer complaint. (EBA Guidelines EBA/GL/2022/15, paragraphs 9–22 and 46–54.)
The initial production release should use Variant A with one approved wallet and issuer combination and a lawful alternative identification route. The institution should control the regulated page and evidence store. The UAE app should receive no readable credential, linked outcome or identifying telemetry from that segment until the onward-processing and transfer conditions are met. Any aggregate reporting still needs a lawful upstream process and effective anonymisation. Monitoring should detect unintended callback, SDK, crash-log and support disclosures. (Regulation (EU) 2016/679, Articles 5, 25, 32 and 44–46.)
After the transfer condition is satisfied, A may return a short-lived result addressed only to the app service. The proposed fields are an opaque transaction reference, the minimum action or completion status, issue and expiry times, and intended audience. The institution should retain the transaction-to-evidence mapping internally, authenticate the result and prevent reuse. The message should omit identity values, detailed rejection reasons and AML suspicion information. The UAE service should delete transient result data after the handoff. Any retained operational record needs its own justified period; the institution's AML period does not automatically apply. Token expiry alone does not delete stored logs or account linkages. (Regulation (EU) 2016/679, Articles 5–6, 13–14 and 32; German Money Laundering Act, § 47.)
Corporate applicants and each additional Member State should follow separate release decisions. For each expansion, the institution must check the accepted identity method, issuer semantics, language, ownership evidence and complaint arrangements. It must reassess the July 2027 AML transition before operating across it. A demand for unrestricted UAE access, indefinite vendor retention, unsupported identity evidence or financial activity outside the permitted role defeats the proposed design and requires the affected service to remain closed. (German Money Laundering Act, §§ 10(9), 12–13 and 17; Regulation (EU) No 910/2014, Article 5b(10); Regulation (EU) 2016/679, Articles 5 and 44–46; Regulation (EU) 2024/1624, Article 90.)