Screen scraping usually depends on user credentials and brittle automation, while API-based access uses explicit authorization and enforceable scopes. The operational difference is control: APIs make consent, revocation, and monitoring visible, whereas screen scraping obscures the access path and expands fraud and credential risk.
Why This Matters for Security Teams
Screen scraping is not just an older integration style. It is a trust problem disguised as automation. A scraper often reuses human credentials, bypasses explicit consent boundaries, and depends on pages staying visually and structurally stable. API-based banking access changes the model: access is granted through scopes, policy, and revocation paths that can be monitored. That distinction matters because identity control is the difference between a managed connection and an opaque one.
For NHI programs, the issue maps directly to what the Ultimate Guide to NHIs describes as visibility, lifecycle control, and offboarding. The risk is not only compromise, but also inability to prove what accessed what, when, and under whose authority. OWASP’s OWASP Non-Human Identity Top 10 reinforces that unmanaged machine access tends to concentrate privilege and weaken governance. In practice, many security teams only discover the difference after a credential leak, a fraud dispute, or a brittle scraper breaking during a site change.
How It Works in Practice
Screen scraping typically works by logging in as a user, loading pages, and extracting data from the rendered interface. That means the access path is tied to a human session, password resets, MFA prompts, layout changes, and whatever anti-bot controls the bank deploys next. API-based banking access is different: the bank exposes explicit endpoints, usually with consented scopes, client credentials, and revocation controls. That makes the integration auditable and far easier to govern as an NHI.
From a security architecture standpoint, API access is closer to zero standing privilege than screen scraping ever can be. A well-designed API flow can use short-lived tokens, delegated consent, and narrow permissions, with logs that show which workload requested which action. That is consistent with the lifecycle guidance in the Ultimate Guide to NHIs — Key Challenges and Risks, especially where long-lived secrets and poor offboarding create durable exposure. The practical goal is not simply “no passwords”; it is enforceable identity, bounded scope, and rapid revocation.
For regulated financial access, these properties also align better with external assurance expectations. The EU EU Cyber Resilience Act is not a banking integration standard, but it reflects the wider regulatory direction toward secure-by-design connectivity and accountable software behavior. In the same spirit, the NHI research in 52 NHI Breaches Analysis shows why unmanaged machine access repeatedly turns into breach material. These controls tend to break down when a bank has no supported API for the needed function, forcing teams back to brittle browser automation.
Common Variations and Edge Cases
Tighter API governance often increases integration overhead, so organisations have to balance security gains against legacy constraints and business timelines. Not every bank exposes the same API surface, and there is no universal standard for full feature parity across account types, transaction types, and dispute workflows.
In some environments, screen scraping persists as a temporary bridge while API coverage expands. Current guidance suggests treating that as an exception with compensating controls: dedicated service accounts, strong credential vaulting, least-privilege permissions, session monitoring, and aggressive rotation. But even then, the risk profile remains worse than API-based access because the control plane is still borrowed from human authentication. That is why the Ultimate Guide to NHIs — What are Non-Human Identities is useful here: a machine connection should be treated as a distinct identity, not a disguised user session.
Another edge case is consented data aggregation, where users expect convenience but not necessarily durable session reuse. Banks and fintechs increasingly prefer API-mediated access because revocation is cleaner and monitoring is richer. Scraping may still appear “simpler” for developers, but simplicity shifts the burden onto fraud teams, legal review, and incident response. Best practice is evolving toward explicit machine identity and consented API scopes because that is the only model that scales cleanly across revocation, audit, and partner oversight.
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 NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers unmanaged machine credentials and opaque access paths. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is central to API scopes versus scraper sessions. |
| NIST Zero Trust (SP 800-207) | AC-3 | Zero Trust favors explicit authorization and revocation over implicit trust. |
Inventory every banking integration as an NHI and remove credential-sharing patterns.
Related resources from NHI Mgmt Group
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between protecting applications and protecting access?
- What is the difference between onboarding access and NHI provisioning?
