API access uses a dedicated interface that the bank provides for authorised third parties, while screen scraping imitates customer access to retrieve data from the online channel. Under the RTS, screen scraping is no longer allowed where a dedicated API exists, and third parties using the fallback approach must digitally sign messages to identify themselves. The API model is more controlled and easier to govern.
How PSD2 payment account access changes when an API replaces screen scraping
Under PSD2 payment account rules, the difference is not just technical convenience. API access is a purpose-built channel the account servicing payment service provider exposes for authorised third parties, so access, consent handling, message format and logging can be governed directly. Screen scraping, by contrast, reuses the customer-facing web journey, which makes control weaker and operational behaviour less predictable.
The practical distinction is that API access gives the bank and the third party a stable integration boundary, while screen scraping depends on how the online channel behaves that day. That matters for security, availability and auditability because the API model can enforce explicit permissions and structured responses, whereas scraping inherits whatever breaks in the consumer interface. The shift is also why PSD2 pushed the market toward more controllable access paths, rather than reuse of the login page. For a broader view of how account access, secrets and permissions need to be governed, see Ultimate Guide to NHIs.
Where the rules are applied as intended, API access is the more governable design because it separates customer authentication from third-party access and reduces the temptation to share credentials or mimic a human session. That separation also makes it easier to apply consistent rate limits, message signing, consent checks and fraud monitoring. The general API risk profile is well covered in the OWASP API Security Top 10, especially where authorisation and resource exposure are concerned.
Why the fallback model is tighter and more brittle than the API model
PSD2’s fallback approach exists because API availability is not always perfect, but it is not a free pass back to password replay. The fallback path is more constrained because it still needs the third party to identify itself and to preserve accountability for each request. In practice, that makes it closer to a regulated exception than a normal integration pattern.
Screen scraping is brittle for two reasons. First, it depends on the presentation layer, so any change to page structure, MFA flow, session handling or anti-bot controls can break the integration without warning. Second, it tends to blur roles, because the third party is effectively acting through customer-style interaction rather than through a distinct technical trust relationship. That increases operational risk and makes troubleshooting harder when a transaction fails or a bank changes its portal. For implementation detail on the web side of those controls, OWASP Web Security Testing Guide is the better reference point than generic access-control advice.
By contrast, a dedicated API usually gives both sides clearer boundaries for consent, scope and incident review. If the integration fails, the bank can distinguish between an authentication issue, a transport problem and a permission problem. With screen scraping, those fault lines are often collapsed into one brittle browser session, which increases support overhead and weakens traceability. The difference is not merely cosmetic, it changes how confidently the access model can be governed at scale.
What practitioners should watch when comparing API access and scraping
The main practitioner error is treating screen scraping as if it were just another connector. It is usually a last-resort compatibility path, not the preferred operating model. If a dedicated API exists, teams should expect the API to become the default control point for consent, revocation, monitoring and third-party assurance, while treating scraping as a higher-friction exception that deserves tighter review.
What to verify: confirm whether the access route is a true PSD2-compliant API, a regulated fallback channel, or an improvised browser automation flow. Then check whether the third party can be uniquely identified, whether requests are traceable, and whether the bank can revoke access without disturbing the customer’s own channel.
Decision rule: if the use case can be served by the dedicated interface, prefer it because it is easier to govern and less likely to break when the web front end changes. If a fallback path is still being used, treat it as an exception that needs explicit ownership, monitoring and periodic review rather than an ordinary integration choice.
Practitioner takeaway: the core issue is not API versus browser automation in the abstract, it is whether the access path creates a distinct, auditable trust boundary. If it does not, governance, revocation and incident response all become harder than they need to be.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | PSD2 access paths depend on tightly governed permissions and revocation. |
| 12 — Network Infrastructure Management | Dedicated APIs and scraping flows create different exposure points and trust boundaries. | |
| Recommendation — Apply Access Control Management to restrict third-party account access and revoke unused pathways quickly. Segment and monitor the API path separately from customer web channels. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity and Access Control | Authorised third-party access must be uniquely identifiable and governed. |
| PR.PS-03 — Configuration Change Management | Screen scraping breaks when portal changes alter the customer-facing flow. | |
| DE.CM-08 — Network Traffic Monitoring | API use and scraping have different observable request patterns and abuse signals. | |
| Recommendation — Enforce identity and access controls for each third-party payment account connection. Manage channel changes so they do not silently disrupt payment-account integrations. Monitor request patterns to detect abnormal third-party access behavior. | ||
| NIST SP 800-63 | IAL — Identity Proofing | Payment account access depends on trusted identity binding for the participant. |
| Recommendation — Use strong identity proofing where the access model depends on verified parties. | ||
| NIST Zero Trust (SP 800-207) | ID — Identity as the New Perimeter | API access is governed by explicit trust relationships rather than shared web sessions. |
| Recommendation — Bind access decisions to verified identity and policy rather than channel reuse. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Fallback or API-based access still depends on credentials, tokens and signing material. |
| NHI-03 — Authorization and Least Privilege | Third-party payment access should be limited to only the data and actions consented to. | |
| NHI-06 — Discovery and Inventory | Banks need to know which third parties use APIs, fallback access or scraping-style paths. | |
| Recommendation — Protect and rotate the credentials used to identify third-party payment access. Scope each payment-account integration to the minimum approved access. Inventory every third-party payment-account access path and review its legitimacy. | ||
Related resources from NHI Mgmt Group
- What is the difference between screen scraping and API-based banking access?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between static access rules and evidence-based access decisions?
- What is the difference between AI agent access and ordinary service account access?
