Contents

1 Introduction

Currence Holding B.V. (hereafter: Currence) is the Product and brand owner of the Schemes iDEAL (payment), iDIN (identification service) and eMandates (Incassomachtigen; electronic issuing of valid direct debit mandates). These three Schemes have the same system of Roles, with virtually the same requirements for the Roles of the Products. Therefore a common set of requirements of the Products is written, grouped in the Online Rules & Regulations (R&R).

1.1 Currence Schemes

A Scheme is a system of agreements, consisting of governance agreements, role descriptions, rules and legal conditions, referred to as Rules & Regulations (hereafter: R&R), including a set of technical requirements, grouped in the /wiki/spaces/SPEEL/pages/33731039. This document provides a general explanation of the Schemes and the on these Products based R&R. The R&R clarify the rules and agreements governing all relevant activities relating to the Products of Currence. 

The explanation covers the following topics:

• the background to the development of the R&R; see section 2;

• a more detailed description of the various Roles relating to the iDEAL, iDIN and eMandates Schemes; see section 3;

• a description of the R&R, including an explanation of the Acceptance Regulations, the Certification Procedure, the Licence and Certification Structure and an explanation of the R&R documents, including the /wiki/spaces/SPEEL/pages/33731039; see section 4.

2 Background to the Rules & Regulations

Currence is the Product owner and trademark holder for the iDEAL, iDIN and eMandates Schemes and all Products based on them. In that capacity, it defines and manages the requirements regarding the various Roles that feature in the various Currence Schemes, with Currence taking into account the wishes from the market.

The Schemes have been developed to facilitate making iDEAL payments, digital online identification with iDIN and exchange of personal data or issuing eMandates from/by a User to a Merchant via the online or mobile banking environment (hereafter: Online Channel) of the Issuer.

The R&R, including the /wiki/spaces/SPEEL/pages/33731039, is owned by Currence. In that capacity, it defines and manages the requirements regarding the various Roles that feature in the Schemes and the underlying Products. These requirements are necessary for the Products to operate effectively for all parties concerned. The requirements are objective, non-discriminatory, and not more stringent than strictly necessary. A set of rules, the Online R&R, has been drawn up in order to set out the requirements in practical terms. Currence consults its Licencees and Certificate Holders when drawing up or amending the rules.

The R&R contain the established rules and also a description of the Roles and activities that parties involved in the Products can carry out. In that context, Currence issues Licence and Certificate Agreements.

Currence helps safeguard the efficiency, quality (including reliability and image) and the integrity of its Products. Currence carries out the following tasks:

• determining the strategy and policy of the Schemes;

• developing and, if necessary, revising the Schemes and the underlying Products;

• drawing up, laying down, and managing the Online R&R;

• certifying Licencees and Certificate Holders;

• accreditation of Accredited Parties;

• monitoring Licencees and Certificate Holders (with the power to impose sanctions) and Accredited Parties;

• coordinating anti-fraud measures;

• facilitating collective consultation structures;

• public relations, public affairs, communications, brand promotion.

3 Description of Currence Schemes

3.1 iDEAL

iDEAL is the online service with which Users can easily make payments by using the Authentication Tools for the Online Channel of their own Issuer.

The iDEAL Scheme covers:

• Issuers and Acquirers who are licensed by Currence iDEAL B.V.;

• CPSPs who are certified by Currence iDEAL B.V.;

• C2C Providers who are accredited by Currence iDEAL B.V.

The Roles have been defined for the iDEAL Scheme so that a User can use the Online Channel to make iDEAL Payments to a Merchant (such as a webshop or invoice company) or an other person (C2C). These payments are debited from the User's account and credited to the recievers account.

To be able to make iDEAL Payments, the User must have a current account with access to the Online Channel of its Issuer. The Merchant must have an iDEAL contract with an Acquirer or CPSP that provides the option to offer his Users to pay via iDEAL. A C2C Provider will handle the C2C Payments.

The Issuer guarantees payment of the iDEAL funds (effected by Users) to the Acquirer, for iDEAL transactions given the irrevocable status of ‘Successful’, as documented and communicated to the Acquirer through the iDEAL message protocol. The iDEAL message protocol is described in the /wiki/spaces/SPEEL/pages/33731039. The Issuer debits the User’s account in accordance with the requirements in the SCT Rulebook. An iDEAL Payment is easily recognisable as such by Users. The description of the iDEAL transaction in the Online Channel (bank statement) always contains a 16-figure iDEAL Transaction number. The number can be used by the Issuer and the Acquirer to clarify the status of the iDEAL Payment, in case something is not clear at a later stage.

The Acquirer guarantees its Merchants, CPSPs or C2C Providers that iDEAL payments made by the User will be credited, if the iDEAL transaction has the irrevocable status of ’Successful’, as documented and communicated in the iDEAL message protocol, which is described in the /wiki/spaces/SPEEL/pages/33731039. The Acquirer should credit the iDEAL payments to the business account of the Merchant, CPSP or C2C Provider in accordance with the requirements of the SCT Rulebook. A CPSP should credit the iDEAL Payments to the business account of the Merchant or C2C Provider within the period agreed.
The same security measures used for the existing Online Channels of the Issuers are used for iDEAL-based messages. These Online Channels must meet strict security standards that ensure that financial transactions by Users can be carried out securely.

3.1.1 iDEAL brand

An iDEAL Payment is identified by means of the iDEAL logo, which is protected by trademark law:

iDEAL is a registered logo, of which Currence iDEAL B.V. is the owner. The iDEAL brand is used, among other things, as a feature for the marketing and use of the Product it stands for. The iDEAL brand may only be used in connection with the activities related to it, in accordance with a Licence or Certificate Agreement with Currence iDEAL B.V. to that end.

3.1.2 iDEAL QR

An iDEAL QR payment is identified by means of the iDEAL QR logo, which is protected by trademark law:

iDEAL QR is a registered logo of which Currence iDEAL B.V. is the owner and it has the same conditions as the iDEAL logo.

The QR code is used by a wide audience and can be shown through a variety of channels – invoices, emails, bus shelter posters, other posters, television, smartphones, etc. This gives iDEAL the option of initiating an iDEAL payment via an iDEAL QR code in the following use cases (Figure 1):

• Transfer the Merchant’s transaction from a PC or laptop to a mobile device

• Doorstep donations;

• Paying for video on demand;

• TV fundraising campaigns;

• Paying an invoice;

• Paying bar, hotel, or restaurants bills;

• Paying for purchases at a market;

• Paying for purchases using an online terminal in a shop;

• Paying for purchase from a bus shelter or other poster;

• And so on.

Use cases for an iDEAL payment through iDEAL QR:

3.2 iDIN

iDIN is the online identification service with which Users can easily make themselves known to Merchants by using the Authenticaion Tools for onthe Online Channel of their own Issuer. iDIN is the service that enables natural persons (Users), who have been checked against the requirements of the Money Laundering and Terrorist Financing (Prevention) Act (Wwft), to perform the following actions, via the Online Channel of their Issuer:

• Identifying - The User can identify himself by sharing data with the Merchant. This information is provided on behalf of the User, from the administration of the Issuer;

• Login - The User can log in to the (my environment of the) Merchant by means of a pseudonym, which is agreed upon during an identification transaction. This pseudonym is unique for every User-Merchant-Issuer combination;

• Confirm age - With this product variant the User can indicate whether he / she is 18 years or older. No other data is shared with this variant;

• Signing - With this Product variant, the User can sign documents. This variant can only be carried out via a certified /wiki/spaces/SPEEL/pages/67764352 (DISP).

iDIN enables Merchants to receive data from Users in an efficient manner. The User is redirected from the environment of the Merchant to the Online Channel of his Issuer, where he uses the Authentication Tool provided and logs in to the Online Channel of the Issuer. Then the User gives his Issuer the assignment to provide the data, as shown in the Issuer screens, (encrypted) to the Merchant. The User confirms this assignment with his Authentication tools. After confirming the assignment, the User is redirected to the Merchant's online environment.

IDIN's role model includes

The iDIN Scheme covers:

• Issuers and Acquirers who are licensed by iDIN B.V.;

• Validation Service Providers (VSPs), Routing Service Providers (RSPs) and DISPs who are certified by iDIN B.V.

The Roles have been defined for the iDIN Scheme so that a User can use the Online Channel to send (personal) data to a Merchant. In order to be able to conclude an iDIN contract, the Merchant must meet minimum acceptance criteria.
To authorize the iDIN message, the security measures of the Issuer's Online Channel are used. These Online Channels must meet strict security standards that ensure that iDIN transactions by Users can be carried out securely.

3.2.1 iDIN brand

iDIN is identified by means of the iDIN logo, which is protected by trademark law:

iDIN is a registered logo, which is owned by iDIN B.V. The iDIN logo is used, among other things, as a feature for the marketing and use of the digital identification method it stands for. The iDIN logo may only be used in connection with the activities related to it, in accordance with a Licence or Certificate Agreement with Currence to that end.

3.2.2 iDIN QR

An iDIN QR transaction is identified by means of the iDIN QR logo protected by trademark law:

iDIN QR R is a registered logo of which Currence iDEAL B.V. is the owner and it has the same conditions as the iDEAL logo.

The iDIN QR code is used by a broad public and can be used through various channels - invoices, e-mails, shelters, posters, television, smartphones, etc. - displayed. This also offers iDIN the possibility, for example in a physical shop or at the door, to initiate an iDIN transaction via an iDEAL QR code to check someone's age, for example.

3.3 eMandates

eMandates is an online alternative to the paper mandate for the SEPA Direct Debit (SDD). This facilitates the online confirmation of agreements on the payment methods for services and products for which the User must make single or recurrent payments or payment in arrears. This includes insurance policies, gas and electricity, memberships, charities, instalments and subscriptions.

eMandates enables Merchants to use the Online Channel of the Issuers to receive legally valid electronic payment mandates (eMandates) for standard (Core) or business (B2B) SEPA Direct Debit payments from Users in an efficient manner, in accordance with the SDD Core Rulebook and the SDD B2B Rulebook, without a signature on paper being required. The User is routed from the Merchants environment to its Online Channel of its Issuer, where he or she authenticates himself or herself, using the standard Authentication Tools, and subsequently authorises the mandate in the Online Channel. Afther the  authorisation, the User is routed back to the Merchants online environment.

There are two types of eMandate:

1. An eMandate for the standard SEPA Direct Debit. This can be issued by Users and businesses (SEPA Direct Debit (SDD) Core).

2. The eMandate for the business SEPA Direct Debit. This is for direct debits between businesses (SDD B2B).

By eMandates is meant the issuing, amending and cancelling of a digital Mandate.

Because, on the basis of the SEPA Regulation, Users must also have access to a White List or Black List for direct debits, these are also automatically updated during the issuing process. For business-to-business direct debits, the registration of the mandate details is automatically updated for business Users. If applicable, and to the extent offered by the Issuer, multiple authorization is also offered specifically for business Users.

Finally, the eMandates system of agreements supports the issuing, amendment and cancellation process, although cancellation of the eMandate for standard SEPA Direct Debits (Core) is not processed via the Issuer of the User.

Besides this option of issuing (and amending or cancelling) a mandate online, it remains possible to issue, amend or cancel a mandate on paper. This is also possible for previously issued eMandates or vice versa. The various processes concerning paper mandates and eMandates are described in the Implementation Guidelines of the eMandates Standard and in the SDD Rulebooks.

Through eMandates, the Acquirers, which facilitate eMandates for Merchants, provide Merchants with the option of collecting mandates online using an application that is fast, safe and simple. eMandates enables Users who use a suitable Online Channel to issue a digital mandate so that the Merchant can execute a direct debit on the Users bank account. By means of eMandates, the Issuer, which provide a suitable Online Channel, can offer their Users a fast, safe and simple alternative to paper mandates.

3.3.1 eMandates brand

eMandates are identified by means of the eMandates logo, which is protected by trademark law:

eMandates is a registered logo, which is owned by Currence Incassomachtigen B.V. The eMandates brand is used, among other things, as a feature for the marketing and use of the electronic payment mandate it stands for. The eMandates brand may only be used in connection with the activities related to it, in accordance with a Licence or Certificate Agreement with Currence Incassomachtigen B.V. to that end.

4 Organisation of Currence Schemes

4.1 Message model

The message model developed by Currence is based on a so-called four-party model. Acquirers and Issuers with a Licence offer one or more Products to the market on a commercial basis. This produces benefits for all parties. The model forms the basis for the contents of the iDX Standard and the iDEAL Standard, part of the Online R&R. This is represented in Figure 1. The figure is used to demonstrate the process flow for the Product message in section 4.1.1.

^{Message model}

4.1.1 Process flow for the Product message

1. The User wishes to pay, log in, identify, sign, verify its age and/or  issue a mandate to a Merchant. Therefor the User selects the button for the Product on the Merchant's website and subsequently selects the Issuer with whom the User has access to the Online Channel provided with the correct authorisations and AuthenticationTools;

2. The Merchant sends the request with the data it has requested – directly or through a CPSP or DISP – to the Routing Service Provider (RSP) concerned, in accordance with the message protocol described in the MIG for the Product concerned;

3. The RSP sends the data for the Product concerned to the Validation Service Provider (VSP).

4. The User is then automatically redirected to the Online Channel of his Issuer where the User must authenticate himself;

5. The User then checks the message data in his Online Channel. If he agrees to the payment, mandate and/or provision of the data displayed on the screen⁴ , the User must authorise the message. The User is then automatically redirected back to the Merchant’s web portal. Parameters sent along with the message enable the Merchant to recognise the context (see 2) and therefore the User;

6. The VSP sends the status of the Product message and the data to the Acquirer/RSP. The RSP sends the data of a successful Product message to the Merchant directly or through a CPSP/DISP;

7. The Merchant requests the status of the transaction from the Acquirer/RSP;

8. The Merchant confirms the receipt and displays the content of the message to the User on its own website.

4.2 Contract model

^{Contract model}

The contract model developed by Currence forms the basis of the contents of the Online R&R. This is represented in Figure 2.

The various Roles in the Schemes are explained on the basis of this contract model in sections 4.2.1 to 4.2.8.

4.2.1 Currence

Currence is the Product and brand owner of the iDEAL, iDIN and eMandates, as described in the Online R&R, including the Technical Standards, in which capacity it lays down requirements in relation to the Products and the parties involved in the contract model.

4.2.2 /wiki/spaces/SPEEL/pages/65929472 (Licencee)

The Issuer is the party that has signed a Licence Agreement with Currence. A Licence Agreement is concluded for each Scheme. An Issuer must also have a licence as a Payment Service Provider, or an exemption for this. The Issuer is responsible for the entire Issuing Domain with regard to the activities for the Products, to the extent that they relate to products it has issued/will issue for an appropriate Online Channel. The Issuer is the Institution with which the User has access to the Online Channel by making use of the correct authorisations. The Issuer has an existing or new agreement (e.g. as part of the agreement and/or general terms and conditions for online and mobile banking or payment services; to be filled in by the Issuer) with the User on the basis of which the messages can be authorised. The Issuer facilitates the issuing of the data from its Users by means of messages to the Acquirer. The Acquirer facilitates the issue to the CPSP/DISP or to the Merchant via the RSP or VSP.

An Issuer may only offer Users the Product or Products concerned if it has obtained a Licence from Currence.

4.2.3 /wiki/spaces/SPEEL/pages/67633182 (VSP; Certificate Holder)

The VSP is the party that has signed a Certificate Agreement with Currence. A Licence Agreement is concluded for each Scheme. The VSP has an agreement with, and operates on behalf and under the responsibility of, one or more Issuers. The VSP is responsible for processing message traffic concerning the issuing of messages by the Issuers. The VSP must be able to connect to all RSPs in the Schemes.
A VSP may only participate in the Product or Products if the VSP has been certified by Currence and has concluded a VSP contract with at least one Issuer that is in possession of a Licence Agreement with Currence.

4.2.4 User

The User is the individual with access to the Online Channel of his Issuer provided with the correct authorisations and Authentication Tools. The User can authorise the Product message through the Online Channel of the Issuer concerned. The User has an agreement (e.g. as part of the agreement and/or general terms and conditions for the Online Channel; to be filled in by the Issuer) with the Issuer concerning the use of the Products. A User of iDEAL and eMandates can be either a natural person⁶ or a business entity. A User of iDIN can only be a natural person.
A User is not subject to any requirements on the part of Currence. Any obligations will be imposed on the User by the Issuer.

4.2.5 /wiki/spaces/SPEEL/pages/67567687 (Licencee)

The Acquirer is the party that has concluded a Licensing Agreement with Currence. A Licence Agreement is concluded for each Scheme. An Acquirer must also have a licence as a Payment Service Provider, or an exemption for this. Furthermore the Acquirer concludes Product contracts with Merchants / CPSPs / DISPs for the Products concerned. The Acquirer is responsible for the entire Acquiring Domain with regard to the activities for the Products, to the extent that they concern its Merchants and Certificate Holders. The Acquirer is responsible for the correct processing of the issuing of the messages for its Merchants, which have been sent by a User who purchases a product from a Merchant. The Acquirer concludes a contract with an RSP to that end.
An Acquirer may only offer Merchants and Certificate Holders the Products concerned if it has obtained a Licence from Currence.

4.2.6 /wiki/spaces/SPEEL/pages/67600565 (RSP; Certificate Holder)

The RSP is the party that has signed a Certificate Agreement with Currence (a Licence Agreement is concluded for each Scheme) and that has an agreement with or is part of the Acquirer. The RSP offers its service for the routing of a Product message, initiated by a User by means of the Online Channel of his Issuer via the website of the Merchant or the CPSP/DISP. The RSP is responsible for ensuring that the Product messages are received, verified, processed and forwarded correctly. The RSP makes agreements with an Acquirer concerning the processing of Product messages for the Merchants, Users of an Acquirer or CPSP/DISP. The RSP has an agreement with, and operates on behalf and under the responsibility of, one or more Acquirers. The RSP must be able to connect to all VSPs in the Schemes.
An RSP may only participate in a Scheme if the RSP has been certified by Currence and has concluded an RSP contract with at least one Acquirer that is in possession of a Licence Agreement with Currence.

4.2.7 /wiki/spaces/SPEEL/pages/67698838 (CPSP) / /wiki/spaces/SPEEL/pages/67764352 (DISP) ) – both Certificate Holders

CPSP
The main objective of a CPSP is 'to mediate in the settlement of iDEAL payments for its Merchants for its own account and risk'. This means that the CPSP collects the iDEAL payments on behalf of and as agreed with it Merchant. And after collecting the CPSP will transfer the iDEAL payments to the business account of its Merchant. The CPSP makes it possible for the Merchant to offer iDEAL, together with other payment products, via the internet checkout to their Users. Furthermore, the CPSP can arrange the technical aspects of the connection of the iDEAL message traffic with the Acquirer, in accordance with the /wiki/spaces/SPEEL/pages/33731039 and with the Merchant, in accordance with the technical connection agreed with the Merchant. 

The CPSP makes agreements with its Merchants concerning iDEAL and concludes iDEAL contracts with its Merchants itself, in accordance with the Online R&R, including the annex ‘/wiki/spaces/SPEEL/pages/68747408’.

A CPSP may only participate in iDEAL if the CPSP has been certified by Currence and has concluded a CPSP contract with at least one Acquirer that is in possession of a Licence Agreement with Currence. In addition, a CPSP must have a licence as a Payment Service Provider, or an exemption for this. 

DISP

A DISP can arrange the technical aspects of the connection of the iDIN message traffic with the Acquirer, in accordance with the Merchant Implementation Guide (MIG) and with the Merchant, in accordance with the technical connection agreed with the Merchant. The DISP is, in contrast to the iDEAL CPSP, not visible to the User. After all, the User only agrees to its Issuer for sending its iDIN data to the Merchant, not to the DISP. An exception to this rule is when the DISP also offers the Product variant iDIN Signature and is certified for this. In this case, the DISP may be visible in the iDIN message traffic. The DISP can also decrypt and process (e.g. forwarding) the User’s personaldata for the Merchant in a safe and secure manner.

The DISP is the party that has signed a Certificate Agreement for iDIN with Currence. The DISP makes agreements with its Merchants concerning iDIN and concludes iDIN contracts with its Merchants itself, in accordance with the Online R&R, including the annex ‘/wiki/spaces/SPEEL/pages/68747408’.

A DISP may only participate in iDIN if the DISP has been certified by Currence and has concluded a DISP contract with at least one Acquirer that is in possession of a Licence Agreement with Currence. A DISP that also wants to offer iDIN Signature needs to go through additional certification with Currence.

4.2.8 /wiki/spaces/SPEEL/pages/67633373 (Accredited Party)

Through its C2C Service, a C2C Provider provides a consumer the opportunity to transfer money to and/or receive money from another consumer. The iDEAL payment is made to (the IBAN of) the C2C Provider. The C2C Provider must then transfer the money to the IBAN of the Private Recipient within the agreed period of time. The C2C Provider makes clear to every party to whom it provides the C2C service what his C2C service entails and what the rights and obligations of this party are.

A C2C Provider may only participate in the iDEAL Scheme if the C2C Provider has been accredited by Currence.

4.2.9 eMandates Service Provider (MSP; Accredited Party)

The MSP can provide the technical aspects of the connection to the eMandates service on behalf of the Creditor and ensures the correct flow of the eMandates messages. The MSP may also facilitate in the conclusion of the eMandate contract between the Creditor and the Creditor Institution. The MSP can only facilitate eMandates contracts for Creditors who have a valid SDD contract with a Creditor Institution.

An MSP may only participate in the eMandates service if the MSP has been accredited by Currence.

4.2.10 Merchant

The Merchant is the party that has concluded a contract with an Acquirer, CPSP or DISP in order to use a Product. The Merchant offers goods or services to Users in accordance with the Product conditions prescribed by the Acquirer, CPSP or DISP, which, as a minimum, also include the provisions as described in the R&R Online annex '/wiki/spaces/SPEEL/pages/68747408'. If the Merchant purchases this service, the Merchant must provide its Users with the opportunity to authorise a Product transaction via the Online Channel of their Issuer.

Currence has no direct relationship with a Merchant. The Acquirer, CPSP or DISP is responsible for onboarding a Merchant, in accordance with the requirements as stated in the R&R Online annex '/wiki/spaces/SPEEL/pages/68747408' and 'Guidelines and Use of Product Logos' as well as the /wiki/spaces/SPEEL/pages/33731039. 

4.2.10.1 Platform as an iDIN Merchant

A platform as a Merchant within the iDIN Scheme is a party that provides a service or software to its business customers (hereinafter sub_Merchants). The User can deliver its iDIN data via the platform to the sub_Merchants of the platform (Merchant). These sub_Merchants will make use of the platform's iDIN service and can offer iDIN as a Product to the User.

A platform as Merchant has the advantage that all its sub_Merchants do not have to enter into a separate iDIN contract with a DISP or Acquirer, but they can enter into a single contract with the platform (Merchant) for all services offered by the platform.

Examples of platforms (not exhaustive):

• taking out loans / mortgages / insurances;

• payroll administration software packages;

• software packages for the administration of nurseries.

NB An Acquirer or DISP must report a platform to Currence.

The environment of the sub_Merchant can be reached after iDIN verification via the platform (Merchant). The sub_Merchant chooses to join the platform, which allows Users to access the online environment of sub_Merchant. The sub_Merchant hereby determines the purposes and means for the processing of Personal Data, whereby the sub_Merchant chooses to process the personal data of their Users via the verification system of the platform and iDIN for verification purposes. 

• The platform as an iDIN Merchant only fulfills the role of intermediary (with access to iDIN) (platform = processor);

• Allowing the User to authenticate itself with the party (sub_Merchant) from which it wishes to purchase a service (sub_Merchant = controler).

4.3 Earnings model

The earnings model is based on the mutual contractual relationships between the parties involved in the Schemes, see Figure 3. Acquirers and Issuers (with a Licence Agreement), CPSPs and DISPs (Certificate Holders) and C2C Providers and MSPs (Accredited Parties) offer the Products to the market commercially. They can charge their User or Merchant a fee for this, the interpretation of which is at the Institutions' discretion. The Institutions must draw up a mutual agreement on a Fee, if applicable. Currence charges its Licencees and Certificate Holders a fee.

^{Earnings model}

5 Rules & Regulations, including Technical Standards

5.1 Online R&R

Currence has adopted a uniform set of rules, the Rules & Regulations (R&R), which are to be adhered to by every Licencee, Certificate Holder and Accredited Party for each Scheme. Among other things, the R&R include rules covering all relevant activities relating to the Schemes. Currence has compiled the R&R with great care, taking the relevant laws and regulations as the starting point.

The requirements in respect of the various Roles, as described in section 4.2, can be divided into those of a general organisational nature and those that relate to the process associated with the Role fulfilled by the party within the Scheme. The process comprises the various relevant activities that together make up the complete Role. The process-related requirements can be divided into quality requirements and, where necessary, additional detailed requirements of a more operational nature. All requirements are recognisable as such in the documents and, where applicable, are accompanied by explanatory notes.

With regard to the activities for which rules have been made in the R&R, a distinction is made between the Issuing Domain and the Acquiring Domain. The Issuing Domain comprises all activities relating to the authentication of the User by the Issuer and the authorisation of the message by the User. Based on the User’s authorisation, the Issuer provides the requested data as indicated in the message to the Acquirer. The Acquirer facilitates the issue to the CPSP/DISP or to the Merchant via the RSP. The Acquiring Domain comprises all activities relating to the receipt and processing of the message by the Acquirer (through the RSP) on behalf of a Merchant / CPSP / DISP.

For both the Issuing and Acquiring Domain, the Licencees must comply with the relevant laws and regulations that apply to them, and with the rules and guidelines prescribed by the regulators in the country where the organisation is based.

5.1.1 Licence and Certificate structure

Institutions wishing to join one of the Schemes must conclude a Licence, Certificate or Accreditation Agreement with Currence:

• Institutions wishing to fulfil the Role of Issuer or Acquirer are eligible for a Licence Agreement. Licencees are responsible for all activities in their domain.

• Institutions wishing to fulfil the Role of VSP, RSP, CPSP or DISP are eligible for a Certificate Agreement. Certificate Holders are responsible for the activities associated with their Role. Institutions wishing to fulfil the Role of Certificate Holder are eligible for a Certificate Agreement.

• Institutions wishing to fulfil the Role of C2C provider or MSP are eligible for an Accreditation Agreement. Accredited Parties are responsible for the activities associated with their Role. Institutions wishing to fulfil the Role as an Accredited Party qualify for an Accreditation Agreement.

5.1.2 Acceptance and Acceptance Regulations

An Institution shall be eligible for a Licence or Certificate Agreement if it has demonstrated that it meets the Acceptance Requirements associated with the Role that the Institution wishes to fulfil in the Scheme. The Acceptance Regulations form the basis for this. The acceptance procedure listed here describes the steps the Applicant must take in order to be certified for the Role in question. To start the acceptance procedure, the Institution must send a signed Application Form to Currence for approval. Currence will then send a set of documents to the Institution, including the R&R. The certification procedure will then start.

5.1.3 /wiki/spaces/SPEEL/pages/65994808

 The certification procedure mainly involves carrying out a Control Self Assessment (CSA). A CSA is used by the Applicant to demonstrate that it meets the requirements associated with the Role that the Applicant wishes to fulfil in a Scheme or Schemes.

The certification procedure covers the activities that the Applicant must perform in order to be able to fulfil a Role as described in the R&R. The certification procedure comprises the following stages:

1. Carrying out a Control Self Assessment (CSA) by the Applicant/Institution;

2. Evaluation of the CSA by Currence;

3. Selective verification by Currence to establish the accuracy of the CSA (and therefore of the implementation of the R&R by the Applicant);

4. Successful conclusion of the test set by means of the Test Tool (TT);

5. The Applicant must carry out product verification tests with all Licencees and Certificate Holders already certified;

6. A new Issuer must have its issuer screens assessed by Currence;

7. Final evaluation and decision by Currence concerning the granting of a Licence and/or Certificate Agreement;

8. Monitoring of compliance with agreements to rectify any outstanding issues (of minor importance) revealed by the certification process.

NB If an Institution does not fulfil all functions of its Role, the Institution must declare the provisions regarding the functions concerned ‘Not Applicable’ during certification for the Role in question.

5.1.4 /wiki/spaces/SPEEL/pages/33731039

Currence provides a Technical Standard in the R&R. For iDEAL this is the iDEAL Standard and for iDIN and eMandates these are the iDx Protocol and the Implementation Standard. The Technical Standard describes the message traffic of a Product message. The Merchant Implementation Guide (MIG) is available for the technical implementation of the Merchant, CPSP or DISP.

5.2 R&R documentation

Currence is in no way liable for errors or omissions or the consequences of later amendments to the documentation. The R&R consist of the following documents:

1. General Notes (this document)
   This gives an outline description of the Schemes, with the Roles and Products associated with them.

2. Agreements
   Licence Agreement: The agreement concluded by a Licencee with Currence after successfully completing the Certification Procedure for the Scheme or Schemes in which it wishes to take part. The Fees annex also applies here;
   Certificate Agreement: The agreement concluded by a Certificate Holder with Currence after successfully completing the Certification Procedure for the Scheme or Schemes in which it wishes to take part. The Fees annex also applies here;

   Accreditation Agreement: The agreement concluded by an Accredited Party with Currence after successfully completing the accreditation procedure for the Product iDEAL or eMandates.

3. General Regulations
   /wiki/spaces/SPEEL/pages/66093148: description and applicability of the General Regulations;
   /wiki/spaces/SPEEL/pages/66093191: definition of terms in the Online R&R that start with a capital letter;
   /wiki/spaces/SPEEL/pages/66093222: duties and powers of the members of the Council of Licencees;
   /wiki/spaces/SPEEL/pages/65831020: description of how parties may communicate in relation to the Schemes;
   /wiki/spaces/SPEEL/pages/66093279: description of how Currence implements changes to the R&R;
   /wiki/spaces/SPEEL/pages/66093292: description of when Currence may impose a penalty on a Licencee or Certificate Holder. /wiki/spaces/SPEEL/pages/66093292 also applies here;
   /wiki/spaces/SPEEL/pages/66093320: description of how and when a Bilateral Fee is applicable.

4. Acceptance Regulations and Certification Procedure
   Acceptance Regulations: description of the procedure established by Currence that is used to assess whether an Applicant may be accepted to the Scheme concerned in order to be able to fulfil the Role it has applied for;
   /wiki/spaces/SPEEL/pages/65994808: description of the procedure established by Currence that is used to assess whether an Applicant meets the conditions set out in the R&R on the basis of a /wiki/spaces/SPEEL/pages/59277442 (CSA) it has itself carried out.

5. R&R Provisions

   1. /wiki/spaces/SPEEL/pages/65929472: set of provisions that a Licencee who is certified for this Role is obliged to comply with. For iDIN there are additional requirements for the Framework iDIN and Data Quality iDIN;

   2. /wiki/spaces/SPEEL/pages/67633182: set of provisions that a Certificate Holder who is certified for this Role is obliged to comply with;

   3. /wiki/spaces/SPEEL/pages/67567687: set of provisions that a Licencee who is certified for this Role is obliged to comply with;

   4. /wiki/spaces/SPEEL/pages/67600565: set of provisions that a Certificate Holder who is certified for this Role is obliged to comply with;

   5. /wiki/spaces/SPEEL/pages/67698838: set of provisions that a Certificate Holder who is certified for this Role is obliged to comply with; This Role applies only to iDEAL;

   6. /wiki/spaces/SPEEL/pages/67633373: set of provisions that an Accredited Party for this Role is obliged to adhere. This Role only applies to iDEAL;

   7. /wiki/spaces/SPEEL/pages/67764352: set of provisions that a Certificate Holder who is certified for this Role is obliged to comply with; This Role applies only to iDIN;

   8. Mandate Service Provider (MSP):set of provisions that an Accredited Party for this Role is obliged to comply with; This Role applies only to eMandates;

   9. /wiki/spaces/SPEEL/pages/68026369: set of provisions for, among other things, identifying Users to whom an Issuer Licencee is obliged to comply to. These requirements apply only to the iDIN Scheme.

   10. /wiki/spaces/SPEEL/pages/68780088: set of provisions for the dataset which is used within the iDIN Scheme to whom an Issuer Licencee is obliged to comply to. These requirements apply only to the iDIN Scheme.

   11. /wiki/spaces/SPEEL/pages/68780096: set of provisions regarding to the privacy of the data within iDIN, which all licensed and certified iDIN parties are obliged to comply to. These requirements apply only to the iDIN Scheme.

   12. /wiki/spaces/SPEEL/pages/567476279: set of provisions for DISP's who want to offer the iDIN Product variant 'iDIN Signature'.

6. R&R Annexes

   1. /wiki/spaces/SPEEL/pages/103645185

   2. /wiki/spaces/SPEEL/pages/69042229

   3. /wiki/spaces/SPEEL/pages/68845696

   4. /wiki/spaces/SPEEL/pages/68747408

   5. Reporting Obligations for Roles and Products

   6. /wiki/spaces/SPEEL/pages/68747465

   7. /wiki/spaces/SPEEL/pages/68714701

   8. /wiki/spaces/SPEEL/pages/68976872
      Part 2 - Guidelines use iDEAL-logo
      Part 2 - Guidelines use iDIN-logo
      Part 2 - Guidelines use eMandates-logo

7. /wiki/spaces/SPEEL/pages/33731039
   The Technical Standards consist of the following components:
   For iDEAL:
   iDEAL Standard

1. iDx_001 Cover document: an overview of the various documents that form the Technical Standard;

2. iDx_010 Protocol: setting down the technical aspects of the Technical Standards with regard to messages for the relevant Product front-end implementation, to which the parties involved in the Scheme must adhere based on their Roles of Issuer and Acquirer;

3. iDx_025 Messages between Acquirer and Issuer: an overview of the iDx messages exchanged between the Validation Service Provider and the Routing Service Provider;

4. iDx_035 Messages between Merchant and Acquirer: an overview of the iDx messages exchanged between Merchants and Routing Service Providers;
   
   Merchant Implementation Guide (MIG):
   A derivative of the Technical Standard. The MIG gives an overview of the guidelines and recommendations that are relevant for the implementation of iDEAL by Merchants or CPSPs. A Licencee can incorporate relevant Technical Standard matters as information in its own publication of the MIG. The MIG is issued by the Acquirer to the Merchant, CPSP, DISP or C2C Provider.
   
   For iDIN and eMandates:
   iDx Documentation Suite

5. iDx 001 Cover document: an overview of the various documents that form the Technical Standard;

6. iDx_010 Protocol: vsetting down the technical aspects of the Technical Standards with regard to messages for the relevant Product front-end implementation, to which the parties involved in the Scheme must adhere based on their Roles of Issuer and Acquirer;

7. iDx_025 Messages between Acquirer and Issuer: an overview of the iDx messages exchanged between the Validation Service Provider and the Routing Service Provider;

8. iDx_035 Messages between Merchant and Acquirer: an overview of the iDx messages exchanged between Merchants and Routing Service Providers;
   Implementation Guidelines
   A document that describes guidelines concerning the implementation and content of the messages for Issuers and Acquirers.
   Software libraries
   A piece of programming language/software to simplify the technical implementations of Merchants
   Merchant Implementatie Gids (MIG):
   A derivative of the Technical Standard. The MIG gives an overview of the guidelines and recommendations that are relevant for the implementation of the Product concerned by Merchants, CPSPs or DISPs. A Licencee can incorporate relevant Technical Standard matters as information in its own publication of the MIG. The MIG is issued by the Acquirer to the Merchant or DISP.
   

5.2.1 Availability of the Technical Standards

The following is applicable:

1. For access to the Technical Standards, interested parties first need to complete and sign the ‘Technical Standard application form’ and pay a fee.

2. The Technical Standard will only be made available via an intranet website specifically set up for this purpose. This is accessed using a username and password. The applicant is responsible for ensuring that unauthorised persons do not gain access to the intranet website.

5.3 Documentation summary