§What PSD2 requires
Source: Directive (EU) 2015/2366 — Payment Services Directive 2 — accessed 2026-05-11.
Jurisdiction. Applies to payment service providers operating in the EU — including banks and a new category of payment service providers other than banks (PISPs and AISPs). Came into force 13 January 2018; Strong Customer Authentication (SCA) requirement enforced from 14 September 2019.
Personal data definition. PSD2 is not a data-protection regulation; its data definitions sit in the context of payment services. It covers all types of electronic and non-cash payments, such as credit transfers, direct debits, card payments, and mobile and online payments. Personal data flows triggered by PSD2 obligations are governed by GDPR in parallel.
Key requirements relevant to mobile analytics. PSD2's key obligations for mobile-payment-facing apps include Strong Customer Authentication (SCA) — most electronic payments and account-information access require multi-factor authentication using two of: knowledge, possession, and inherence. PSD2 also introduces open-banking access: licensed third-party providers can access account information (AISP) or initiate payments (PISP) on behalf of users, through APIs the bank exposes. The Directive aims to make internet payments easier and safer and to strengthen consumer rights.
⚑Where mobile analytics typically creates exposure for crypto & web3 apps
An analytics SDK that captures payment-flow events — payment_initiated, sca_challenge_shown, authentication_completed — has a clean role if it logs only the event name. But conventional SDKs invite developers to attach transaction amount, recipient, card last-four, or merchant category. Those fields are personal data under GDPR (parallel applicability) and may expand what PSD2 reviewers would scope when assessing the SCA flow's evidentiary chain.
Crypto apps process wallet addresses, transaction hashes, token symbols and amounts, NFT contract addresses, and on-chain holdings. Many also log fiat onramp KYC data, IP geolocation, and device fingerprints for fraud detection.
A wallet address, while pseudonymous on-chain, becomes a persistent identifier under GDPR once any link to a real-world identity exists. Fiat onramp KYC data is personal data outright. Combined with IP and device fingerprints, an analytics SDK can build a persistent profile that triggers GDPR, CCPA/CPRA, and AML/KYC concerns simultaneously.
▸What Respectlytics's design does (technical facts)
Respectlytics's API does not accept wallet addresses or transaction hashes as event parameters — those identify on-chain activity that lives on-chain. Product analytics records that a user opened the swap screen, completed an onramp, or viewed an NFT collection, without per-event identifiers tying those actions to a wallet.
Reduces the surface. Removing the surface where the categories covered by PSD2 could be collected in the first place narrows what a PSD2 review needs to scope. Whether the resulting posture meets the regulation's requirements for your specific app is something to discuss with your legal team.
❓Frequently asked questions
Is using analytics during a payment flow allowed under PSD2?
PSD2 does not ban product analytics. What it requires is that the authentication and authorisation flow itself meets SCA standards and produces appropriate evidence. Recording 'a payment happened' is different from recording 'this card paid this merchant for this amount' — the second form expands both the GDPR and PSD2 evidentiary surface.
How does PSD2 relate to DORA?
Both apply to EU payment institutions; they regulate different surfaces. PSD2 governs the payment services themselves (SCA, open banking, consumer protection). DORA governs the ICT resilience and third-party risk of financial entities including payment institutions. A mobile banking app is typically in scope of both.
Does using Respectlytics by itself resolve PSD2 obligations for our crypto & web3 apps app?
No — and no analytics SDK can credibly answer that question. Whether your product meets PSD2's requirements is a property of your whole product, contracts, and operational practice, evaluated by your legal team. Respectlytics's contribution is a smaller data surface: identifying fields and the regulation's special categories are rejected at the API. Whether that posture, combined with your other controls, satisfies PSD2 for your specific app is a conversation for your counsel.
What if we already use a different analytics SDK today?
The starting point is an inventory of what your current SDK actually collects and where it sends it. Our privacy self-assessment worksheet walks through that in seven sections — it outputs an educational summary you can bring to your legal team.