§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 fintech & mobile banking 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.
Fintech apps process account numbers, transaction amounts, merchant categories, card last-four, IBANs, transfer recipients, and KYC documents. Many also log credit-score read events, loan-application data, and balance snapshots.
Account credentials paired with security codes are sensitive personal information under CPRA. Account numbers and full PANs are personal data under GDPR Art. 4(1) and trigger the PCI-DSS data flow obligations regardless of jurisdiction. Even transaction descriptions can reveal special-category information (e.g., merchant names tied to health, religion, or politics).
▸What Respectlytics's design does (technical facts)
Respectlytics is not your payments processor or your transaction store. It tracks product signals — transfer_initiated, card_added, investment_purchase_completed — without per-event amounts, account numbers, or merchant descriptions. The authoritative financial data lives in your payments backend; product analytics tells you the funnel rate, not the dollar values.
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 fintech & mobile banking 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.