Financial institutions should treat the browser and app as part of the attack surface, not just the backend. That means protecting customer sessions, monitoring transactions for abnormal changes, and detecting malware or injection that can alter payment details. Client-side controls matter because authentication alone does not stop transaction tampering once a session is compromised.
Why Client-Side Fraud Controls Matter Under PSD2 and Open Banking
Under PSD2 and open banking, the fraud problem does not end at authentication. The browser, mobile app, embedded widget, and payment journey all influence whether a payment is genuine or has been altered after login. That means institutions need controls that watch for tampering, suspicious session behaviour, and changes to payment instructions before value leaves the account.
Client-side risk is especially important in open banking because trust is distributed across apps, interfaces, and third-party integrations. If the customer’s session is hijacked or the payment page is manipulated, strong customer authentication can still be satisfied while the transaction itself is redirected, modified, or approved under false pretences.
For institutions operating in European retail payments, the implementation detail matters as much as the policy intent. The EU Digital Operational Resilience Act (DORA) reinforces the need to treat front-end channels, dependencies, and third-party technology as operational risk surfaces rather than as mere presentation layers.
Which Client-Side Failure Modes Create Fraud Exposure?
The main failure modes are session compromise, payment tampering, malicious scripts, and fraudulent redirection of beneficiary data. Attackers do not need to break the core bank ledger if they can change the amount, destination, or authorisation flow in the client context. That is why controls have to inspect behaviour during the journey, not just validate identity at the start.
Another common weakness is overtrust in the user interface. A page can appear normal while injected code silently changes account numbers, swaps payee details, or suppresses warning prompts. Institutions should also assume that customer devices may be unmanaged, shared, or already compromised, which raises the value of step-up checks, transaction signing, and tamper-aware monitoring.
From an implementation standpoint, strong API and session boundaries help limit what a compromised client can do. Open banking integrations should use narrow scopes, audience-restricted tokens, and explicit client authentication controls such as RFC 6749: The OAuth 2.0 Authorization Framework, RFC 8707: Resource Indicators for OAuth 2.0, and, where appropriate, stronger client authentication mechanisms like RFC 7523: JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants.
What Controls Reduce Fraud Without Breaking the Customer Journey?
The most effective controls are those that verify the payment itself, not only the person initiating it. Transaction signing, dynamic linking, behavioural monitoring, device and browser integrity checks, and real-time anomaly detection all help create friction at the right point. The goal is to make tampering visible before execution, while keeping the legitimate path usable enough that customers do not bypass the control.
Open banking also requires disciplined handling of third-party access. If the institution allows payment initiation through APIs or connected applications, least privilege, token scoping, and tight client registration become central controls. Practical identity and access management guidance for financial services is summarised in NHIMG’s Financial Services Identity Security Guide, which covers PSD2, open banking, and related access-control decisions for regulated institutions.
Institutions should also look for hidden exposure in client-side credentials and secrets. Even when the main fraud concern is payment tampering, exposed API keys or shared credentials in front-end code can create the path to abuse. NHIMG’s Google API Keys Exposure, Gemini AI illustrates how client-side exposure can turn into downstream misuse when sensitive material is embedded where it can be harvested or reused.
Risk and Threat Considerations
Client-side fraud is dangerous because it defeats the assumption that successful authentication equals trustworthy intent. If the browser, app, or injected script can alter the payment details after login, the institution may process a validly authorised but fraudulent transaction. That creates direct financial loss, dispute handling cost, and a trust problem that is hard to unwind once funds are moved.
Failure mechanism: Malware, browser injection, session hijack, or malicious third-party code changes payment data, suppresses warnings, or steers the customer into approving the wrong transfer while the backend still sees a legitimate session.
Impact: The bank or payment provider may execute an authorised but manipulated payment, increasing fraud losses, customer harm, reimbursement pressure, and operational burden under PSD2 and open banking.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and DORA and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| DORA | GV.OV — Oversight | DORA applies because client-side fraud is an ICT operational resilience and third-party risk issue. |
| Recommendation — Treat front-end channels and third-party dependencies as operational risk surfaces and monitor them continuously. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service and Non-Organizational Users) | Open banking relies on service and client authentication for payment initiation and API access. |
| Recommendation — Authenticate non-organizational clients with stronger mechanisms and limit trust in shared secrets. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Open banking APIs and payment flows depend on robust client and session authentication. |
| Recommendation — Harden API authentication so a stolen or replayed client session cannot initiate payments. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Client-side fraud detection depends on logging abnormal session and transaction behaviour. |
| Recommendation — Log client, session, and transaction events needed to detect tampering and fraud anomalies. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Payment integrity and transaction signing depend on cryptographic protection of sensitive flows. |
| Recommendation — Use cryptography to protect payment integrity and binding of transaction details. | ||
Practitioner Guidance
What to prioritise: Prioritise controls that verify transaction intent at the point of execution, not just at login. If the payment payload, beneficiary, or amount can change after authentication, treat that as the highest-risk gap.
What to verify: Verify that your anti-fraud stack sees device, session, and transaction signals together. A good control set should be able to flag unusual payee changes, abnormal browser behaviour, and mismatches between the authenticated customer and the final payment attributes.
What good looks like: Legitimate customers complete payments with limited friction, while altered transactions trigger step-up challenge, hold, review, or blocking. The control is working when it reduces fraudulent value movement without simply shifting fraud to another channel.
Practitioner takeaway: For PSD2 and open banking, the key decision is not whether authentication is strong enough, but whether the institution can still trust the transaction after authentication has already succeeded.
Related resources from NHI Mgmt Group
- How should financial institutions reduce fraud risk when onboarding users across stablecoin and banking rails?
- Why does open banking create both innovation benefits and new fraud risk for financial institutions?
- How should financial institutions reduce fraud risk when compliance operations are still fragmented across channels and teams?
- How should financial institutions reduce fraud risk in real-time payments without slowing the user journey too much?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
