About iDIN

iDIN is a Dutch eID scheme directed by the Dutch Payment Association (BVN, Betaalvereniging). It is a collaboration between all major Dutch banks to leverage the familiar authentication process of online banking in order to provide major eID coverage to the Dutch market.
iDIN enables natural persons who have been checked against the requirements of the Money Laundering and Terrorist Financing (Prevention) Act (Wwft) to provide one or several specific pieces of data from the records to Signicat customers, through a channel designed for this purpose by their bank. Additionally, iDIN can also be used in combination with SurePay lookups to enhance the user onboarding process.

Transaction types

iDIN supports 3 transaction types:

  • Login: to authenticate a user
  • Identification: to retrieve user attributes
  • Age check: to check if a user has passed the age of 18

Available attributes

The following information can be obtained from an iDIN identity:

  • Consumer ID (“BIN”) – unique for each merchant
  • Last name
  • Initials of first name
  • Address
  • Date of birth
  • Gender
  • Email
  • Telephone
  • Age confirmation (18 years old: yes/no) – via the age check transaction

The identity information is issued by a bank, and is not linked to (or checked with) the central identity register (BRP – Basisregistratie Personen) in the Netherlands. The Dutch social number (BSN) cannot be obtained via iDIN (yet). The governmental scheme DigiD can do this.

Note: The iDIN scheme and the issuers do not guarantee that they will be able to provide all the requested attributes.

Use case

The consumer visits the merchant’s website and proceeds to log in with iDIN. The merchant redirects to Signicat and Signicat displays a list of banks that the end-user can choose from. The end-user chooses one of the listed banks and authenticates using the bank-specific authentication method they are used to from their bank (for example, a token, card reader, SMS OTP, or app). Signicat then retrieves a confirmation of a successful authentication in addition to the requested end-user attributes and maps the response to a SAML or OIDC response and redirects back to the merchant.


Graphical customization

iDIN generates a form with a dropdown of banks to choose from. This form can be added to an iFrame and used as it is and has no styling by default.

Signicat support will help out with the requirements regarding merchant usage and presentation.

Optionally, Signicat’s standard graphical profile can be used for styling. See this page for more info: Graphical adjustments and customization.

Screenshots (without any graphical profile configured)

iDIN combined with SurePay

iDIN can be used in combination with SurePay, a lookup service. This plugin will make the process of verifying a user’s bank account number much more convenient for both the user and the merchant, with the added benefit that the merchant will be able to gather the user’s personal details from a trusted source.

How it works

  1. The merchant redirects the user to the identity verification process.
  2. The user uses iDIN to authenticate their identity and consents to sharing their identity attributes.
  3. A plugin prompts the user to enter the IBAN of their bank account and provide consent. If the IBAN is already known before starting the identity verification process, it can be included in the redirect URL, in which case the IBAN will be prefilled in this step, and the user will not be able to edit it.
  4. Signicat sends the IBAN (from the plugin) and the user’s identity attributes (from iDIN) to SurePay. The IBAN will always be converted to uppercase, both when it is entered by the user and when it is prefilled.
  5. The merchant gets a response which includes the IBAN, the user’s identity attributes, and whether or not there is a match. If there appears to be a typo in the name, the response will also include a name suggestion. Bear in mind that a message indicating a successful execution does not mean that the IBAN provided by the user is valid or real, just that the communication with SurePay has been successful. The response fields that indicate whether an IBAN is valid and exists are “valid” and “found”, respectively.

If an error prevents the SurePay check from being carried out, only the result of the iDIN authentication will be returned. This includes cases in which the end-user cancels the operation without entering or confirming an IBAN.

iDIN with QR code

The iDIN scheme provides a QR-code scanning service, iDIN QR. The main aim of this service is to give end-users a better user experience on mobile devices. For example, this can be more efficient compared to web flows that require hardware tokens. iDIN QR simplifies the flow and does not require any hardware tokens. If you put the iDIN QR code in the desktop web-flow, end-users can scan their QR code with their mobile device and finalize the iDIN transaction itself on their mobile banking application, before being redirected back to a landing page on the desktop web flow.

End-users can scan QR  codes in two ways:

  • Via a generic QR-code scanning application. This leads to a banking selection page hosted by the IDIN scheme.
  • Directly from the mobile banking application itself. This only applies if the issuing bank supports iDIN QR code scanning.

Use case: Onboarding a new customer

A prerequisite for this use case is that the merchant has an iDIN QR code on their website, which corresponds to a full iDIN identification.

In the following scenario, a prospective customer wants to create an account on a merchant’s website from his/her PC.

  1. The merchant displays the QR code on the web page where the iDIN identification is required (see screen example below).
  2. The prospective customer scans the QR code with the mobile device.
  3. The prospective customer confirms the iDIN transaction on the mobile device and a confirmation screen is displayed on the mobile device (see screen example below).
  4. The prospective customer is redirected to the merchant landing page where the original QR code was shown.

The merchant has now received all the attributes from the prospective customer from the Signicat backend and the account can be created based on the validated identity. The customer does not need to enter any other details regarding his/her identity.

Example of how an iDIN QR code looks like (step 1):

Example of a confirmation message on the mobile device (step 3):

Integration details

iDIN QR is available at Signicat through the same OIDC flow as normal iDIN transactions. The reason for this is that you can easily switch between QR-code flows and regular iDIN flows with very limited technical impact.

All existing iDIN methods (identification, login and age verification) are supported through iDIN QR. You must specify which methods you want to present to users when fetching the QR-code from the Signicat backend. You can specify the required methods in the acr_values. Please, see Demo Service for available method names.

This endpoint will return a QR code instead of the usual banking selection screen. You must iframe this QR-code response in the frontend. This requires a subdomain to be setup (see Establishing subdomains).


During the setup of the idinqr method in Signicat, you can change the values of the following parameters of the integration:

  • Expiry time of the QR code: The QR code is valid until the expiry time. The default value is 15 minutes. To change the default value, adjust the expiry date to be QR_DATE + expiry, where expiry can be a value between 10-20 minutes
  • Service URL: After the users are identified, they are redirected to the Service URL. You may customize this URL to be your landing page or another page of your choice. During a transaction with iDIN QR. the user can also see the status page on the mobile. This mobile page can have the following different statuses:
    • Cancelled: During the process, the user chose to select the “Cancel” button.
    • Failed: The iDIN transaction failed and the user may try again.
    • Success: The iDIN transaction was successful and the user gets redirected to the specified URL.
  • Size of QR code: The size of the QR code is shown in pixels. The default value is 300. You can adjust the size between 200-2000 pixels.
  • Language texts: You may adjust the language text that is displayed in both the web and the mobile screen. Note: These language texts are only adjustable for the whole integration and may not be adjusted per method. Signicat can help you with changing the language keys.

Test information

Signicat offers 24/7/365 free access to the preproduction environment,

Starting a transaction in preproduction will result in the following “banks” being available in the issuer list:

The WL Issuer SIM iDIN RABO INT and the Success “banks” will produce successful authentication results with the requested attributes in the response. The other options will produce errors according to the status codes in the dropdown list.

You will not be able to use production bank credentials for testing purposes, however Signicat has built functionality to provide custom test users. If you want to add custom test users to your service, please contact us at The available custom test users and their attributes are as follows:

	"Marnick van de Braak": {
		"urn:nl:bvn:bankid:1.0:consumer.transientid": "TRANS0123456789",
		"urn:nl:bvn:bankid:1.0:consumer.intaddressline1": "Adres 123",
		"urn:nl:bvn:bankid:1.0:consumer.intaddressline2": "1234AB Amsterdam",
		"": "NL",
		"urn:nl:bvn:bankid:1.0:bank.deliveredserviceid": 2,
		"signicat.plain-name": "M van de Braak"
	"Martin Henken": {
		"urn:nl:bvn:bankid:1.0:consumer.bin": "NLRABO0000000001",
		"urn:nl:bvn:bankid:1.0:consumer.intaddressline1": "Adres 123",
		"urn:nl:bvn:bankid:1.0:consumer.intaddressline2": "1234AB Amsterdam",
		"": "NL",
		"signicat.plain-name": "M Henken",
		"urn:nl:bvn:bankid:1.0:bank.deliveredserviceid": 16384
	"Eser Cairo": {
		"urn:nl:bvn:bankid:1.0:consumer.bin": "NLRABO0000000002",
		"urn:nl:bvn:bankid:1.0:consumer.legallastname": "Cairo",
		"signicat.plain-name": "E Cairo",
		"urn:nl:bvn:bankid:1.0:bank.deliveredserviceid": 20480
	"Ünal Roukens": {
		"urn:nl:bvn:bankid:1.0:consumer.bin": "NLRABO0000000003",
		"urn:nl:bvn:bankid:1.0:consumer.legallastname": "Roukens",
		"urn:nl:bvn:bankid:1.0:consumer.dateofbirth": "19750725",
		"signicat.plain-name": "Ü Roukens",
		"urn:nl:bvn:bankid:1.0:bank.deliveredserviceid": 20928
	"Armand van Binsbergen": {
		"urn:nl:bvn:bankid:1.0:consumer.bin": "NLRABO0000000004",
		"urn:nl:bvn:bankid:1.0:consumer.legallastnameprefix": "van",
		"urn:nl:bvn:bankid:1.0:consumer.legallastname": "Binsbergen",
		"urn:nl:bvn:bankid:1.0:consumer.18orolder": false,
		"signicat.plain-name": "A van Binsbergen",
		"urn:nl:bvn:bankid:1.0:bank.deliveredserviceid": 20544
	"Theodoor Sijbers": {
		"urn:nl:bvn:bankid:1.0:consumer.bin": "NLRABO0000000004",
		"urn:nl:bvn:bankid:1.0:consumer.legallastnameprefix": "van",
		"urn:nl:bvn:bankid:1.0:consumer.legallastname": "Binsbergen",
		"urn:nl:bvn:bankid:1.0:consumer.street": "Utrechtplein",
		"urn:nl:bvn:bankid:1.0:consumer.houseno": "127",
		"urn:nl:bvn:bankid:1.0:consumer.postalcode": "5709DK",
		"": "Helmond",
		"signicat.plain-name": "T Sijbers",
		"urn:nl:bvn:bankid:1.0:bank.deliveredserviceid": 21504
	"Anders Notten": {
		"urn:nl:bvn:bankid:1.0:consumer.bin": "NLRABO0000000005",
		"urn:nl:bvn:bankid:1.0:consumer.legallastname": "Notten",
		"urn:nl:bvn:bankid:1.0:consumer.intaddressline1": "Vagnvägen 76",
		"urn:nl:bvn:bankid:1.0:consumer.intaddressline2": "45678 Ballefjongberga",
		"": "SE",
		"signicat.plain-name": "A Notten",
		"urn:nl:bvn:bankid:1.0:bank.deliveredserviceid": 21504
	"Martha de Goedbloed-Stokkink": {
		"urn:nl:bvn:bankid:1.0:consumer.bin": "NLRABO0000000006",
		"urn:nl:bvn:bankid:1.0:consumer.initials": "M",
		"urn:nl:bvn:bankid:1.0:consumer.legallastnameprefix": "de",
		"urn:nl:bvn:bankid:1.0:consumer.legallastname": "Goedbloed",
		"urn:nl:bvn:bankid:1.0:consumer.preferredlastname": "Goedbloed-Stokkink",
		"urn:nl:bvn:bankid:1.0:consumer.partnerlastname": "Stokkink",
		"urn:nl:bvn:bankid:1.0:consumer.dateofbirth": "19750726",
		"urn:nl:bvn:bankid:1.0:consumer.gender": 2,
		"": "",
		"urn:nl:bvn:bankid:1.0:consumer.telephone": "+31666867727",
		"signicat.plain-name": "M de Goedbloed-Stokkinkk",
		"urn:nl:bvn:bankid:1.0:bank.deliveredserviceid": 20950
	"Willeke Liselotte de Bruijn": {
		"urn:nl:bvn:bankid:1.0:consumer.legallastnameprefix": "de",
		"": "",
		"urn:nl:bvn:bankid:1.0:bankid.deliveredserviceid": "21974",
		"urn:nl:bvn:bankid:1.0:consumer.preferredlastname": "Bruijn",
		"urn:nl:bvn:bankid:1.0:consumer.dateofbirth": "19650310",
		"": "NL",
		"urn:nl:bvn:bankid:1.0:consumer.gender": "2",
		"urn:nl:bvn:bankid:1.0:consumer.initials": "WL",
		"urn:nl:bvn:bankid:1.0:consumer.telephone": "+31612345678",
		"urn:nl:bvn:bankid:1.0:consumer.bin": "NLABNA0000000008",
		"urn:nl:bvn:bankid:1.0:consumer.legallastname": "Bruijn",
		"urn:nl:bvn:bankid:1.0:consumer.street": "Pascalstreet",
		"urn:nl:bvn:bankid:1.0:consumer.houseno": "19",
		"urn:nl:bvn:bankid:1.0:consumer.postalcode": "0000AA",
		"": "Aachen",
		"signicat.plain-name": "WL de Bruijn",
		"urn:nl:bvn:bankid:1.0:consumer.preferredlastnameprefix": "de"

In order to fetch the attributes, you can use the following OIDC scopes:

  • profile
  • signicat.idin