Bank Based Digital Identity Guide: Integrating bank eID securely and resisting fraud

Bank-based eID lets a customer prove who they are with the strong authentication their bank already gave them, and that same trust makes a misused bank eID login one of the most valuable things a fraudster can obtain. In several European countries, a bank-issued or bank-backed digital identity is the default way to log in to public services, open accounts and sign contracts. For a relying party, integrating one is quick, but the security of the result depends on choices the relying party makes: how the flow is started, how sessions are bound, which assurance level is requested and how fraud signals are used. This vendor-neutral guide covers the integration patterns, the controls that stop social engineering and session relay, assurance and data handling, rollout and monitoring. Schemes are named only as examples, listed alphabetically: BankID (Sweden) and itsme (Belgium). For the scheme landscape see the National Digital ID Schemes Map; this page goes into implementation and fraud.

Key takeaways

• The relying party owns the start of the flow. Fraud against bank eID usually works by getting a victim to approve a login or signature that a fraudster started, so how the transaction is launched matters more than the cryptography behind it.
• Bind the eID result to the session that asked for it. Animated QR codes, same-device autostart, PKCE, nonce, state and IP comparison all exist to stop a result being used in a different session.
• Request the assurance you need, then check what you got. Ask for the level of assurance in the request and verify the returned assurance claim before granting high-risk actions.
• Show the user what they are approving. Clear text about the service and action in the eID app is a primary defence against scam calls.
• A bank eID login is not the end of fraud checks. Use scheme risk signals and your own device and behaviour signals, and step up for payments, payee changes and contact detail changes.

How bank-based eID works

A bank eID scheme issues a digital identity to a person after their bank has identified them, typically under anti-money-laundering customer due diligence. The person then uses a mobile app (sometimes a card reader or security device) to authenticate to third parties. The relying party (a bank, insurer, public body, telecom or retailer) never sees the user's credential; it receives a signed assertion of identity, and in some schemes a signature over a document.

Whichever pattern you choose, the controls below apply. With a broker, confirm which of them the broker implements and which remain yours.

The fraud model: approving someone else's session

The main threat to bank eID is not breaking the scheme's cryptography but persuading a legitimate user to approve a transaction that a fraudster started. BankID's own explanation for Secure start is direct: fraudsters entered a victim's personal identity number into an e-service, then phoned the victim and persuaded them to approve the request in BankID. BankID states that most BankID-related fraud occurs in e-services that do not use Secure start.

See the Remote Access Scam Prevention for Banks guide and the Authorised Push Payment (APP) Fraud Guide for what happens after the login.

Starting and binding the transaction

Scheme API pattern (example: BankID Sweden)

BankID made Secure start mandatory from 1 May 2024: every transaction must begin with Autostart, when the e-service and the BankID app are on the same device, or with an animated QR code, when they are on separate devices. Static QR codes had to be replaced. The developer documentation sets out the details:

• Animated QR code: the QR data is bankid.<qrStartToken>.<time>.<qrAuthCode>, where qrAuthCode is an HMAC-SHA256 of the time value keyed with qrStartSecret. Regenerate every second on demand. Keep qrStartSecret on the back end, never in the browser.
• Order lifetime: an order is valid for 30 seconds; create a new order to keep showing a code rather than extending one.
• Autostart: pass the autostarttoken via universal link (iOS) or app link (Android), and send the return URL in the back-end order request (the older front-end redirect parameter is deprecated). The return URL must be HTTPS.
• Session binding: put a session nonce in the return URL fragment and verify it server side; compare the ipAddress returned by /collect with the client IP you observed, to mitigate session fixation.
• Polling: call /collect every 2 seconds, with the same certificate that created the order.
• Transport trust: trust the BankID issuer CA in your truststore rather than the leaf certificate, and keep test and production trust separate.

OpenID Connect pattern (example: itsme)

itsme uses the OpenID Connect authorisation code flow. The integration choices that matter for security:

• Client authentication: private key JWT (a signed client_assertion) or client secret, chosen at registration. Prefer private key JWT so no shared secret sits in configuration. See the JWT Client Authentication (private_key_jwt) Guide.
• PKCE: use S256. itsme accepts requests without a code challenge unless enforcement is enabled, and strongly recommends asking onboarding to enforce it. RFC 9700 requires authorisation servers to reject a verifier when no challenge was sent, to block downgrade. See the PKCE Implementation guide.
• State and nonce: itsme strongly recommends both. OpenID Connect Core defines nonce to bind the ID token to the client session and mitigate replay, and state for CSRF protection by binding it to a browser cookie.
• Redirect URIs: exact, case-sensitive match with a preregistered HTTPS URI, no custom scheme and no fragment. RFC 9700 also requires exact string matching.
• Tokens: ID tokens and UserInfo responses are signed and encrypted JWTs; decrypt and verify the signature against the provider's JWK set from the discovery document. The authorisation code is valid for 3 minutes.
• Request objects: where used, authorisation parameters go in a signed then encrypted request JWT, which prevents tampering with scopes and claims in the browser.
• Key rotation: add a new signing key with a new kid before removing the old one; for encryption keys support both during the overlap.

Assurance, claims and data minimisation

Request only the assurance and attributes the use case needs, and check the response.

• Assurance in the request: in OpenID Connect, acr_values requests an authentication context and the acr claim reports what was satisfied. itsme defines acr_basic (fingerprint or itsme code) and acr_advanced (itsme code forced). Reject a response whose acr is lower than the action requires.
• Step-up in scheme APIs: BankID supports a stepUp requirement of mrtd or mrtd+face, adding an identity document check (and face) to authentication or signing for higher-risk actions.
• Minimise identifiers: national identification numbers (for example the Belgian national number claim in itsme) are sensitive. Request them only where a legal basis exists, store a hashed or tokenised form where you only need matching, and apply the purposes rule in GDPR Article 5(1)(b) and (c).
• Evidence for signatures: BankID does not store signature data, so keep the signature and ocspResponse you need for non-repudiation. Decide retention with legal counsel.
• Regulatory context: bank eID used for customer onboarding interacts with anti-money-laundering identification rules, and in the EU with eIDAS notified schemes and the European Digital Identity Wallet. See the eIDAS 2.0 and the European Digital Identity Framework Guide and the Identity Proofing and KYC Guide.

Using risk signals and step-up after login

A successful bank eID authentication proves the right person approved, not that they approved freely. Treat it as one input.

• Scheme risk indication: BankID can return a risk indication (low, medium, high) when the relying party sets returnRisk and sends context such as the end user IP, launch type, domain or app identifier and a device cookie or hardware ID. BankID advises treating it as one input to your own assessment, and an order can be blocked if the risk is too high.
• Payment warnings: BankID payment endpoints can show a predefined warning to the user during approval; keep your own record, because BankID does not store warnings.
• Your own signals: new device, impossible travel, active call or remote access tooling indicators from your mobile app, sudden payee or contact detail changes. See the Account Takeover Prevention Guide.
• Step-up triggers: new payee, raised limits, changed phone number or email, first loan application, and data export. Require a fresh signing transaction with explicit text, not a reused login session.

Implementation roadmap

1. Choose the pattern: direct scheme API, OIDC provider or broker. List which controls in this guide each party owns.
2. Design the start: remove any flow that starts a transaction from a typed national identifier. Implement same-device launch and animated QR codes for cross-device.
3. Bind sessions: PKCE S256 with enforcement, state, nonce, exact redirect URIs, server-side return URLs with a session nonce, and IP comparison at completion.
4. Protect relying party credentials: keep the relying party certificate private key or private key JWT key in an HSM or managed key store, with an owner, expiry monitoring and a rotation runbook.
5. Set assurance per action: map each action to the required acr or step-up and enforce it server side.
6. Write user-visible text: name your service and the action ("Log in to Example Bank", "Sign loan agreement for EUR 5,000") in every request that supports it.
7. Test: use the scheme's test environment and test identities; test cross-device relay, expired orders, cancelled transactions, replayed codes and mismatched IPs. Run a red team scenario of a scam call against your own flow.
8. Roll out in stages: pilot with staff and a small customer group, with the previous login method available as a fallback; remove the fallback after metrics settle. Rollback is a configuration switch back to the old method, owned and logged.

Detection and measurement

Log each transaction with the order reference or ID token jti, flow type (same-device or cross-device), returned assurance, risk indication, client IP at start and completion, and the action authorised.

Where identity fits

The relying party's own credential is a non-human identity with outsized reach: a BankID relying party client certificate or an itsme private key JWT key lets its holder request identity assertions in the organisation's name. Inventory it, restrict who can export it, monitor its use and rotate it on schedule. See the Customer IAM (CIAM) Guide for how bank eID fits alongside passwords, passkeys and account recovery.

Framework mapping

Common failure patterns

• Typed-identifier start retained "for convenience". It recreates the exact path scam callers use.
• QR secret in the front end. Exposing the QR secret lets anyone generate valid codes for the order.
• PKCE optional. The provider accepts requests without a challenge unless enforcement is switched on.
• Login session reused for signing. A payment or contract approved on the strength of a login hours earlier, with no explicit signing text.
• Ignoring returned assurance. Requesting a higher level but not checking the acr claim.
• Expired relying party certificate. An unowned certificate expires and every eID login fails at once.

Practitioner checklist

• Remove every flow that starts a bank eID transaction from a typed identifier.
• Use same-device launch or animated QR codes regenerated every second, with secrets on the back end.
• Enforce PKCE S256, state, nonce and exact redirect URIs for OIDC schemes.
• Verify session nonces and compare start and completion IPs.
• Request the assurance each action needs and reject lower acr values.
• Show the service name and action in the eID app for every request.
• Feed scheme risk indications into your fraud engine and step up for payee, limit and contact changes.
• Store relying party keys in an HSM or managed key store with expiry alerts and a rotation runbook.
• Minimise and protect national identifiers, and keep signature evidence you need.

Standards and references

• BankID: Developer documentation (RP API v6)
• BankID: Secure start will be mandatory from 1 May 2024
• itsme: Authentication with OpenID Connect
• IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
• OpenID Foundation: OpenID Connect Core 1.0
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: National Digital ID Schemes Map · Customer IAM (CIAM) Guide · PSD2/PSD3 Strong Customer Authentication Guide · Digital Identity Wallets Guide