PSD3 and the EU Payment Services Regulation (PSR) do not just update the payments rulebook. They raise the standard for fraud controls, monitoring, reimbursement, and proof. The Council describes the agreed package as a “comprehensive anti-fraud framework”. The file still moving through the final legislative steps after a “provisional political agreement” in November 2025 and committee approval of the interinstitutional deal text on 5 May 2026.[1]
This has important implications for mobile because this is where customers log in, complete SCA, add payees, enroll wallets, change limits, and approve payments. But it is also where many institutions still have the weakest evidence. When a payment is disputed, teams may know what the backend received, yet still struggle to show what happened on the device, what risks were present, and how those signals shaped the decision.
That is the mobile protection-and-evidence gap. As PSD3 and the EU PSR move closer to adoption, protection alone is a weaker position. Banks and PSPs need evidence that helps explain how high-risk mobile journeys were protected, what signals were available, and how decisions were made.
This checklist is designed to test that. It is an operational checklist, not a legal one. Use it to assess whether your mobile channel can support fraud decisions, investigations, reimbursement handling, and audit with trusted evidence, not just backend records.
SCA (Strong Customer Authentication) stays at the center of the framework under PSD3/PSR. The agreed text keeps the PSD2 logic that authentication should use elements from “different categories”, with only a narrow exception around inherence. It also says firms should not make authentication depend on “a smartphone or another smart device” alone.[2]
So, the real question is not just which factors were used. It is whether the app and device were in a trusted state when authentication happened.
Learn more: Broken authentication
For example, a bank may have strong biometric or possession-based controls on paper. But that security narrative weakens quickly if the mobile app can be overlaid, hooked, tampered with, or driven inside an untrusted runtime during login or approval.
A strong answer to this question means you can show whether the app and device were in a trusted state when SCA was performed and tie that evidence to the session in question.
The risk does not begin and end at login. It shows up in payee creation, wallet enrolment, limit changes, payment initiation, and payment approval. The agreed PSR makes monitoring more explicit and says it should take account of “signs of malware infection” during authentication sessions.[3]
Learn more: Mobile malware and Mobile malware downloaded from third-party app stores
Some of the most damaging fraud scenarios do not look suspicious from the server side. Remote access, overlay abuse, runtime instrumentation, accessibility misuse, screen capture, and app tampering can all shape a payment journey without changing the final request in a way backend systems can easily explain.
If you cannot detect tampering, overlays, or runtime interference during those high-risk moments, you are missing fraud context where the commercial and regulatory stakes are highest. A strong answer means you can detect interference where it happens, while the session is live, not only after the case lands in an investigation queue.
Signals only matter if they can shape action in time. The package is not only about collecting better fraud data. It is about using it. The agreed text says monitoring should happen before execution, and it allows action where there are “reasonable grounds to suspect fraud”.[3]
Learn more: Insufficient logging and monitoring
If mobile evidence reaches the fraud team only after the payment has gone through, the problem is not visibility. It is timing. Mobile signals existing somewhere means little. They must reach the right controls fast enough to influence a decision.
A weak answer to this question collects signals after the event or leaves them sitting in dashboards. A strong answer routes those signals into the fraud engine, SIEM, or risk layer while the payment journey is still live, so protection can shape action and later support proof.
When a payment is challenged, backend records rarely tell the full story. Teams need to know what happened on the device, whether the app was running in a trusted environment, whether manipulation was detected, and what signals were present before approval. That matters more under PSD3 and the EU PSR because preventive tools, reimbursement decisions, and PSP liability are now more tightly linked.[4]
A strong answer means your evidence lets investigators rebuild the mobile side of the story: app state, device risk, controls triggered, and signals available before approval. It is the basis for explaining what the app saw, what controls fired, and why the case was handled the way it was.
Not every disputed payment is the same. Some cases involve genuine customer mistakes. Others involve impersonation, social engineering, technical compromise, or a mix of these. The agreed package responds directly to newer scam patterns, including “spoofing fraud”, and raises the bar for what firms should do before and during a payment flow.[1]
Better mobile evidence will not remove every grey area. But it gives fraud and compliance teams a stronger basis for deciding what likely happened. That means your mobile evidence should help teams move beyond guesswork.
A strong answer doesn't mean that you always know with 100% certainty. But it does mean you can rule technical compromise in or out far more reliably than before, and you can show how that assessment was made.
One common weakness is fragmentation. Fraud teams see one dataset. Security teams see another. Audit and compliance teams often work from summaries that strip away the detail. That does not hold up well when a regulator, auditor, or internal reviewer asks what happened, what signals were available, and what action was taken.
A stronger model gives those teams a shared core evidence record, translated for their needs. That means consistent timestamps, severity, and enough context to support fraud operations, incident response, reimbursement handling, and review.
A long stream of mobile events is not the same as useful evidence. Product analytics may explain screens, journeys, or performance, but they do not usually explain compromises. The agreed PSR points toward a more operational use of payer-side information, including behavioral characteristics, session data, and device data, for fraud prevention.[3]
Useful telemetry should therefore be structured, timestamped, severity-tagged, and easy to route into the systems fraud and security teams already use. It should tell analysts what happened, where it happened, and how confident they should be in the signal.
A strong answer here is one that lets an analyst quickly understand what happened on the device before the payment was approved and use that evidence without having to reconstruct the story from scratch.
Read more: How to make mobile attack telemetry useful for fraud, security operations, and audit teams
PSD3 and the EU PSR raise expectations for better monitoring, but they do not remove the need for disciplined data handling. The agreed text says relevant monitoring data should be kept no longer than necessary and, in any event, no longer than five years after the end of the customer relationship.[5]
Teams should therefore be clear on what is collected, what is excluded, who can access it, and how long it is retained. Stronger evidence should support investigations without creating a new governance problem. That means a clear privacy model and retention model that is aligned with broader governance.
A strong answer to this means your telemetry is useful enough to support fraud operations and investigations but also disciplined enough to stand up in a privacy review too.
Read more: What’s new in PSD3 compared to PSD2? 7 changes banks and PSPs should watch
A mobile control is not fully mature when it exists only in policy text or architecture diagrams. Under the agreed package, firms will need to show that preventive tools, monitoring measures, and payment controls are not only defined, but put into use.[1]
For mobile, that means being able to explain what threats are monitored and how signals reach fraud or security teams. Can you demonstrate what happens when the app detects tampering, overlays, or signs of runtime compromise? Can you produce sample evidence when a case is reviewed, without exposing unnecessary personal data?
A strong answer means you not only have documentation, but a documented control area with evidence to match. Mobile is no longer a black box in your control framework.
This is the question that brings the checklist together. Many institutions already do some form of mobile application hardening, and that is an important start. But the agreed package pushes the market beyond prevention alone.
The stronger position is not only to block attacks, but also to show what the app saw, what controls were triggered, what signals were available, and how those signals shaped action. Under PSD3 and the EU PSR, that shift from protection to proof is where mobile readiness becomes real, and where compliance starts to depend on evidence rather than assumption.
Read more: Protection is not intelligence: Why blocking mobile threats is no longer enough
This checklist matters because it turns a broad regulatory discussion into a practical test. You do not need perfect answers to every question today. But you do need a clear view of where the mobile channel is protected, where it is blind, and where it still cannot produce usable evidence.
If you cannot show that SCA happened in a trusted environment, if you cannot rebuild a disputed session, or if mobile signals never influence fraud decisions, then mobile is still under-documented in one of the most important parts of the payment journey. That is where the next phase of PSD3 preparation will be won or lost.
The firms that move fastest will not be the ones with the longest policy documents. They will be the ones that can protect the mobile channel, observe what happens inside it, and turn those signals into evidence that fraud, security, compliance, and audit teams can rely on. Under PSD3 and the EU PSR, that is the real standard: not protection alone, but protection that can be proven.
[1] The Council and Parliament reached a “provisional political agreement” on 27 November 2025. On 5 May 2026, the European Parliament’s ECON committee approved the “provisional agreement resulting from interinstitutional negotiations” on the PSR file. The Council says the package aims to fight payment fraud more effectively, increase transparency, strengthen consumer protection, and create a “comprehensive anti-fraud framework”. The European Parliament Legislative Observatory currently shows the file as awaiting Council’s 1st reading, so formal adoption is still pending.
[2] The compromise PSR text keeps the core SCA model, with at least two elements from “different categories”, while allowing a narrow two-inherence exception. It also says authentication methods should not depend on “a smartphone or another smart device” alone.
[3] The compromise text makes transaction monitoring more explicit. It says monitoring should take account of “signs of malware infection” in authentication sessions and allows action where there are “reasonable grounds to suspect fraud”.
[4] The Council’s summary highlights “spoofing fraud”, payee verification before transfer, and liability where PSPs fail to use preventive tools properly. That is why better mobile evidence now matters more to investigations, reimbursement handling, and control review.
[5] The compromise text says relevant monitoring data should not be stored longer than necessary and, in any event, no longer than five years after the termination of the customer relationship.
Council press release on the provisional PSD3/PSR agreement, 27 November 2025
Council final compromise text for the Payment Services Regulation (PSR), ST 8221/26
Council final compromise text for PSD3, ST 8222/26
European Parliament Legislative Train status page for the payment-services revision