| Insert excerpt | ||||||
|---|---|---|---|---|---|---|
|
...
Contents
| Expand | ||
|---|---|---|
|
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).
| Info |
|---|
Currence iDEAL B.V., Currence Incassomachtigen B.V. and iDIN B.V. are subsidiaries of Currence Holding B.V. |
1.1 Currence Schemes
| Note |
|---|
In the Online R&R you wil find terms ware defined are all written with an initial capital. The meanings of these terms which are used have been laid down in definitions. The definitions are listed in alphabetical order in the section /wiki/spaces/SPEEL/pages/66093191. |
...
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.
...
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 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:
...
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:
...
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:
...
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.
...
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
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;
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;
The RSP sends the data for the Product concerned to the Validation Service Provider (VSP).
The User is then automatically redirected to the Online Channel of his Issuer where the User must authenticate himself;
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 screen4 , 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;
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;
The Merchant requests the status of the transaction from the Acquirer/RSP;
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.
| Info |
|---|
When Issuers carry out the Role of VSP themselves, this Role is certified together with the Role of the Issuer (for iDEAL, the VSP Role is not applicable). The Institution receives a Licence for the Role of Issuer and a Certificate for the Role of VSP. |
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 person6 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.
| Info |
|---|
When Acquires carry out the Role of RSP themselves, this Role is certified together with the Role of the Acquirer (for iDEAL, the RSP Role is not applicable). The Institution receives a Licence for the Role of Acquirer and a Certificate for the Role of RSP. |
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.
...
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.
...
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.
...
| Info |
|---|
Note regarding iDEAL:
|
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.
...
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.
...
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.
| Info |
|---|
An Accredited Party does not have to go through a certification procedure. An iDEAL C2C party is required to complete the questionnaire. |
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.
...
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:
...
General Notes (this document)
This gives an outline description of the Schemes, with the Roles and Products associated with them.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.
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.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.R&R Provisions
/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;
/wiki/spaces/SPEEL/pages/67633182: set of provisions that a Certificate Holder who is certified for this Role is obliged to comply with;
/wiki/spaces/SPEEL/pages/67567687: set of provisions that a Licencee who is certified for this Role is obliged to comply with;
/wiki/spaces/SPEEL/pages/67600565: set of provisions that a Certificate Holder who is certified for this Role is obliged to comply with;
/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;
/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;
/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;
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;
/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.
/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.
/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.
/wiki/spaces/SPEEL/pages/567476279: set of provisions for DISP's who want to offer the iDIN Product variant 'iDIN Signature'.
R&R Annexes
/wiki/spaces/SPEEL/pages/33731039
The Technical Standards consist of the following components:
For iDEAL:
iDEAL StandardiDx_001 Cover document: an overview of the various documents that form the Technical Standard;
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;
iDx_025 Messages between Acquirer and Issuer: an overview of the iDx messages exchanged between the Validation Service Provider and the Routing Service Provider;
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 SuiteiDx 001 Cover document: an overview of the various documents that form the Technical Standard;
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;
iDx_025 Messages between Acquirer and Issuer: an overview of the iDx messages exchanged between the Validation Service Provider and the Routing Service Provider;
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:
For access to the Technical Standards, interested parties first need to complete and sign the ‘Technical Standard application form’ and pay a fee.
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
...