EPC e-mandates e-operating Model. Detailed Specification

Transcription

1 Doc: EPC April 2013 Version 1.2 Approved EPC EPC e-mandates e-operating Model Detailed Specification Abstract Document Reference Issue This is the Detailed Specification for the development of the EPC e-operating Model supporting e-mandates in the SEPA Direct Debit Scheme. EPC Version 1.2 Approved Date of Issue 9 April 2013 Reason for Issue Reviewed by Produced by Authorised by Circulation Update EPC EPC EPC Publicly available Conseil Européen des Paiements AISBL Cours Saint-Michel 30 B 1040 Brussels Tel: Fax: Enterprise N secretariat@epc-cep.eu 2012 Copyright European Payments Council (EPC) AISBL: Reproduction for non-commercial purposes is authorised, with acknowledgement of the source

2 TABLE OF CONTENTS 0 DOCUMENT INFORMATION REFERENCES DEFINED TERMS CHANGE HISTORY PURPOSE OF DOCUMENT MANAGEMENT SUMMARY VISION AND OBJECTIVES VISION OBJECTIVES READING ROADMAP EPC E-OPERATING MODEL OVERVIEW FOUR CORNER MODEL SCOPE E-OPERATING MODEL PARTIES PRINCIPLES MODEL DESCRIPTION MESSAGE FLOWS SECURITY ROUTING AND INTEROPERABILITY IMPLEMENTATION GUIDELINES GENERAL REQUIREMENTS DEBTOR REQUIREMENTS CREDITOR REQUIREMENTS ROUTING SERVICE PROVIDER REQUIREMENTS VALIDATION SERVICE PROVIDER REQUIREMENTS DIRECTORY SERVICE REQUIREMENTS CERTIFICATION AUTHORITY REQUIREMENTS MESSAGE SPECIFICATION NOTATION CONVENTIONS EPC E-OPERATING MODEL MESSAGES ERROR CODES TERMS USED IN THE DOCUMENT ANNEX A XML SCHEMAS A.1 EOM-COMMON.XSD A.2 EOM-STATUS.XSD A.3 EOM-MSG-CRED-TO-RS-001.XSD A.4 EOM-MSG-RS-TO-VS-001.XSD A.5 EOM-MSG-VS-TO-RS-001.XSD A.6 EOM-MSG-RS-TO-CRED-001.XSD A.7 EOM-MSG-CRED-TO-RS-002.XSD A.8 EOM-MSG-RS-TO-VS-002.XSD A.9 EOM-MSG-VS-TO-RS-002.XSD A.10 EOM-MSG-RS-TO-CRED-002.XSD EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 2-9 April 2013

3 ANNEX B XML MESSAGE SAMPLES B.1 EOM-MSG-CRED-TO-RS B.2 EOM-MSG-RS-TO-VS B.3 EOM-MSG-VS-TO-RS B.4 ERROR EOM-MSG-VS-TO-RS B.5 EOM-MSG-RS-TO-CRED B.6 ERROR EOM-MSG-RS-TO-CRED B.7 EOM-MSG-CRED-TO-RS-002 FOR RETRIEVAL OF AN E-MANDATE B.8 EOM-MSG-RS-TO-VS-002 FOR RETRIEVAL OF AN E-MANDATE B.9 EOM-MSG-VS-TO-RS B.10 ERROR EOM-MSG-VS-TO-RS B.11 EOM-MSG-RS-TO-CRED B.12 ERROR EOM-MSG-RS-TO-CRED B.13 EOM-MSG-CRED-TO-RS-002 FOR ACKNOWLEDGEMENT OF AN E-MANDATE B.14 EOM-MSG-RS-TO-VS-002 FOR ACKNOWLEDGEMENT OF AN E-MANDATE ANNEX C RECOMMENDED STRATEGIES FOR BIC RESOLUTIONS C.1 ONLINE RESOLUTION C.2 OFFLINE RESOLUTION ANNEX D CERTIFICATE ENROLMENT REQUIREMENTS D.1 AUTHENTICATION CERTIFICATE FOR ROUTING SERVICE PROVIDERS D.2 AUTHENTICATION CERTIFICATE FOR VALIDATION SERVICE PROVIDERS D.3 SIGNING CERTIFICATE FOR VALIDATION SERVICE PROVIDERS ANNEX E X.509 CERTIFICATE PROFILES E.1 ROUTING SERVICE AUTHENTICATION CERTIFICATE PROFILE E.2 VALIDATION SERVICE AUTHENTICATION CERTIFICATE PROFILE E.3 SIGNING CERTIFICATE PROFILE EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 3-9 April 2013

4 FIGURES FIGURE 1: E-MANDATE CONCEPTUAL FOUR CORNER MODEL FIGURE 2: E-OPERATING MODEL FIGURE 3: SIMPLE AUTHORIZATION MESSAGE FLOW FIGURE 4: MULTIPLE AUTHORIZATIONS MESSAGE FLOW FIGURE 5: SIGNIFICANT STEPS OF THE CERTIFICATE VERIFICATION FIGURE 6: ENVELOPING XML SIGNATURE FIGURE 7: ELECTRONIC SIGNATURE VERIFICATION FIGURE 8: PKI AND CERTIFICATES FOR THE E-OPERATING MODEL FIGURE 9: E-OPERATING MODEL - OPTIONS FOR DIRECTORY SERVICES FIGURE 10: SIGNIFICANT STEPS OF THE CERTIFICATE VERIFICATION FIGURE 11: SEQUENCE DIAGRAM OF THE SINGLE AUTHORIZATION MESSAGE FLOW FOR CREDITORS 40 FIGURE 12: SEQUENCE DIAGRAM OF THE MULTIPLE AUTHORIZATIONS MESSAGE FLOW FOR CREDITORS 40 FIGURE 13: STATE DIAGRAM FOR TRANSACTIONS IN CREDITORS FIGURE 14: SEQUENCE DIAGRAM FOR ROUTING SERVICE PROVIDERS FIGURE 15: STATE DIAGRAM FOR TRANSACTIONS IN ROUTING SERVICE PROVIDERS FIGURE 16: SEQUENCE DIAGRAM OF THE SINGLE AUTHORIZATION MESSAGE FLOW FOR VALIDATION SERVICE PROVIDERS FIGURE 17: SEQUENCE DIAGRAM OF THE MULTIPLE AUTHORIZATIONS MESSAGE FLOW FOR VALIDATION SERVICE PROVIDERS FIGURE 18: STATE DIAGRAM OF THE SINGLE AUTHORIZATION MESSAGE FLOW FOR TRANSACTIONS IN VALIDATION SERVICE PROVIDERS FIGURE 19: STATE DIAGRAM OF THE MULTIPLE AUTHORIZATIONS MESSAGE FLOW FOR TRANSACTIONS IN VALIDATION SERVICE PROVIDERS FIGURE 20: XML SCHEMA MODULES FOR THE EPC E-OPERATING MODEL FIGURE 21: GRAPHICAL XML SCHEMA OF MESSAGE EOM-MSG-CRED-TO-RS FIGURE 22: GRAPHICAL XML SCHEMA OF MESSAGE EOM-MSG-RS-TO-VS FIGURE 23: GRAPHICAL XML SCHEMA OF MESSAGE EOM-MSG-VS-TO-RS FIGURE 24: GRAPHICAL XML SCHEMA OF MESSAGE EOM-MSG-RS-TO-CRED FIGURE 25: GRAPHICAL XML SCHEMA OF MESSAGE EOM-MSG-CRED-TO-RS FIGURE 26: GRAPHICAL XML SCHEMA OF MESSAGE EOM-MSG-RS-TO-VS FIGURE 27: GRAPHICAL XML SCHEMA OF MESSAGE EOM-MSG-VS-TO-RS FIGURE 28: GRAPHICAL XML SCHEMA OF MESSAGE EOM-MSG-RS-TO-CRED FIGURE 29: ONLINE BIC RESOLUTION FIGURE 30: CACHING OF FULL BIC RESOLUTION TABLES FIGURE 31: OFFLINE BIC RESOLUTION EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 4-9 April 2013

5 TABLES TABLE 1: PROPOSED READING ROADMAP TABLE 2: SINGLE AUTHORIZATION MESSAGE FLOW DESCRIPTION TABLE 3: MULTIPLE AUTHORIZATIONS MESSAGE FLOW DESCRIPTION TABLE 4: DESCRIPTION OF THE E-OPERATING MODEL CERTIFICATES TABLE 5: XADES-BES PROFILE FOR THE EPC E-OPERATING MODEL TABLE 5: XADES-BES PROFILE FOR THE EPC E-OPERATING MODEL TABLE 6: DESCRIPTION OF MESSAGE EOM-MSG-CRED-TO-RS TABLE 7: DESCRIPTION OF MESSAGE EOM-MSG-RS-TO-VS TABLE 8: DESCRIPTION OF MESSAGE EOM-MSG-VS-TO-RS TABLE 9: DESCRIPTION OF MESSAGE EOM-MSG-RS-TO-CRED TABLE 10: DESCRIPTION OF MESSAGE EOM-MSG-CRED-TO-RS TABLE 11: DESCRIPTION OF MESSAGE EOM-MSG-RS-TO-VS TABLE 12: DESCRIPTION OF MESSAGE EOM-MSG-VS-TO-RS TABLE 13: DESCRIPTION OF MESSAGE EOM-MSG-RS-TO-CRED TABLE 14: ERROR CODES EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 5-9 April 2013

6 0 DOCUMENT INFORMATION 0.1 References This section lists external references mentioned in this document. Use of square brackets throughout this document is used to reference documents in this list. N.º Document Number Title Issued by: [1] EPC SEPA Scheme Management Internal Rules EPC [2] EPC SEPA Direct Debit Scheme Implementation Guidelines EPC [3] EPC SEPA Core Direct Debit Scheme Rulebook Annex VII e- Mandates [4] EPC SEPA Business to Business Direct Debit Scheme Rulebook EPC [5] EPC Risk Mitigation in the SEPA Direct Debit Scheme EPC [6] EPC Customer-to-Bank Security Threat Assessment EPC [7] EPC Approval Scheme for EPC Approved CAs EPC [8] SPTF-029/05 Impact of the EESSI Standards on the European Banking Community [9] EPC Customer-to-Bank Security Good Practices Guide EPC [10] EPC e-mandates e-operating Model - High-level Definition EPC [11] EPC SEPA e-mandates messages definition EPC [12] ISO Information processing systems Open Systems Interconnection Basic Reference Model Part 2: Security Architecture, 1989 [13] ISO 9362 Bank Identifier Codes (BIC) ISO [14] ISO [15] ISO [16] ISO [17] ISO [18] RFC 2560 Financial services - International bank account number (IBAN) - - Part 1: Structure of the IBAN Financial Services Universal Financial Industry Message Scheme Information technology Security techniques Information security management systems Fundamentals and vocabulary Information technology Security techniques Information security risk management Internet X.509 Public Key Infrastructure Online Certificate Status Protocol OCSP EPC EPC ISO ISO ISO ISO ISO IETF [19] RFC 2616 Hypertext Transfer Protocol HTTP/1.1 IETF [20] RFC 3339 Date and Time on the Internet: Timestamps IETF [21] RFC 3986 Uniform Resource Identifier (URI): Generic Syntax IETF [22] RFC 5246 The Transport Layer Security (TLS) Protocol IETF [23] RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile IETF [24] XML Extensible Markup Language (XML) 1.0 W3C [25] XMLDSIG XML Signature Syntax and Processing W3C EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 6-9 April 2013

7 N.º Document Number [26] CWA Title Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures - Part 1: System Security Requirements, 2003 CEN Issued by: [27] CWA Security requirements for signature creation applications, 2004 CEN [28] CWA [29] TS [30] TS Guide on the Use of Electronic Signatures Part 1: Legal and Technical Aspects, 2004 Policy requirements for certification authorities issuing qualified certificates, version Policy requirements for certification authorities issuing public key certificates, version CEN ETSI ETSI [31] TS XML Advanced Electronic Signatures (XAdES), version ETSI [32] TS [33] IP/08/803 [34] Dir.1999/93/EC Profiles of XML Advanced Electronic Signatures based on TS (XAdES), version An unlimited source of Internet addresses to be on stream in Europe by 2010 Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a community framework for electronic signatures ETSI European Commission European Council [35] OECD Broadband Subscriber Criteria OECD [36] [37] NIST Guidelines for the Issuance and Management of Extended Validation Certificates, version 1.1 Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations CAB Forum NIST 0.2 Defined Terms This document refers to various defined terms, which have a specific meaning in the context of this document. Chapter 6 includes a full list of defined terms used in this document. 0.3 Change History Issue number Dated Reason for revision v1.0 August 2008 First document v1.1 2 September 2010 Added Multiple Authorisations Message Flow XML signature algorithm is RSA with SHA-256 Deleted reference to enrolment process managed by the EPC in section 3.8 v1.2 9 April 2013 Added the EPC Base OID to Annex E EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 7-9 April 2013

8 0.4 Purpose of Document This document defines the EPC e-operating Model. It takes as a basis the e-mandates Service Description of the Core SDD [3] and the B2B SDD [4] and builds up an operating model that will be detailed in the following chapters: Vision and Objectives Introduces the Detailed Specification; the context in which it is being developed, the scope of applicability, its vision and objectives. EPC e-operating Model Overview Documents the EPC e-operating Model, covering the description of the operating model, the description of the parties of the model, message flows, routing, interoperability and the security concept, Implementation Guidelines Identifies the requirements and procedures to be implemented by each of the participants in the EPC e-operating Model. Message specification Describes the protocol messages exchanged in the EPC e- Operating Model. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 8-9 April 2013

9 1 MANAGEMENT SUMMARY The e-mandate service is an optional feature complementing the SDD Schemes. The process of issuing an e-mandate will allow Debtors and Creditors to exchange mandates in a fully electronic way, presenting advantages for Debtors, Creditors, Creditor Banks, and Debtor Banks. The objective of the e-mandates is to replace the paper in the Mandate Flow, allowing the Debtors to issue, to amend and to cancel a Direct Debit Mandate through electronic means, while the collection process stays the same as in the existing SDD Scheme. A Bank involved in the e- Mandate service may choose to act as Debtor Bank and/or as Creditor Bank for offering the e- Mandate related services. The Creditors may offer an optional functionality by allowing Debtors to amend and cancel paper based mandates electronically. The e-mandate is based on the Four Corner Model of the SDD Scheme and it adds two new entities that play a key role in the e-mandates flow: the Routing Service and the Validation Service. To implement the e-mandate solution, the e-mandate service description needs to be completed by a set of ISO XML Standards messages and a technical standard (the EPC e-operating Model). The EPC e-operating Model focuses on applicational data transport over the Internet between the Creditor Websites and Validation Services, through a Routing Service. The requirements and procedures to be implemented by each party on the EPC e-operating Model are defined in this document, as well with the XML schemas for the data transport and certificate profiles. The requirements, data transport, security and authentication mechanisms between Debtor and Validation Service are out of scope of this document. The Validation Service is expected to deploy a set of mechanisms coherent with the Debtor Bank security policy. This model considers that the total transaction time to request an e-mandate should be acceptable to the Debtor, providing a fluid and responsive user experience. The transport mechanism supports the transmission of account access, data validation (BIC, IBAN, etc) and is prepared for future enhancements such as multiple authorizations. The EPC e-operating Model is designed to allow the issuance, amendment and cancellation of e- Mandates with a clear focus on reachability and interoperability between different Routing Service providers and Validation Service providers. In this model, it is necessary to have the support of a Directory Service and Certification Authorities, in order to offer a trusted connection between Routing Services and Validation Services. Routing Service providers use Directory Services as enablers for reachability to all trusted participant Debtor Banks, while EPC approved Certification Authorities are used to securely qualify legitimate Validation Service providers and Routing Service providers. Two possible message flows are defined for the EPC e-operating Model: the Single Authorization Message Flow that is applicable when just a single authorization from an account holder is needed to issue an e-mandate and the Multiple Authorization Message Flow (MAMF) that is applicable when authorizations from n different account holders are needed to issue an e-mandate (a typical B2B scenario). The essential steps of the EPC e-operating Model are as follows (for the issue of an e-mandate): The Debtor using a browser initiates the creation of an e-mandate on the Creditor s Website, by entering all the required elements (including the operational BIC). EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 9-9 April 2013

10 The Creditor Website creates the e-mandate proposal and submits it to a Routing Service of the Creditor Bank. In order to identify the Validation Service, the Routing Service queries a Directory Service using the BIC provided by the Debtor. The Routing Service submits the e-mandate proposal to the Validation Service of the Debtor Bank. Mutual authentication between the Routing Service and the Validation Service is achieved by using certificates issued according to EPC requirements. The Validation Service performs the validation of the BIC, IBAN (if provided) and account access rigths. The Debtor is routed from the Creditor s Website to the Validation Service for the validation of the Debtor s authenticity. The Debtor must identify and authenticate himself according to the instructions received from the Debtor Bank. After a successful authentication, the Debtor confirms the e-mandate and is routed back to the Creditors Website. The signed e-mandate is delivered to the Creditor through the initial Routing Service. The Creditor Website acknowledges the reception of the e-mandate and confirms this to the Debtor. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 10-9 April 2013

11 2 VISION AND OBJECTIVES 2.1 Vision The e-mandate process is an optional feature complementing the Core Scheme 1. This process will allow Debtors and Creditors to agree on mandates in a fully electronic way. If an e-mandate process is offered then each of the process of issuing, amendment and cancellation of e-mandates must be possible in an electronic way and cannot be offered separately. In addition, the Debtor Bank has an important role in the authentication of (i.e. checking the due authority of the person claiming to be) the Debtor ("validation"). This will allow the complete avoidance of paper administration in the mandate flow, while the collection process stays the same as in the existing Core Scheme. [3], 1.2. The e-mandate service is built upon the e-operating Model that has the objective of establishing a trusted platform for models with a similar structure implemented over open networks, assuring adequate levels of security and interoperability. The e-operating Model defines a platform to guarantee secure and reliable transactions between parties communicating over the internet. This assurance is achieved through contractual relationships between the parties and their respective banks, and through an infrastructure that provides a trusted environment for the interactions between parties. The e-operating Model covers aspects such as guaranteed delivery, non-repudiation, data integrity and encryption of exchanged information as well as authentication of the involved parties and is aligned with the EPC business requirements (e-mandates Service Description [3] and B2B scheme [4]), rules and best practices. 2.2 Objectives This document is intended for the use of any party that requires a detailed understanding of the EPC e-operating Model. Although this model is being devised to support e-mandates, the design has taken into account that it should also support other services based on the four corner model. In this sense, references to e-mandate throughout this document can be seen in generic terms as an authorization. Thus, whenever an authorization is required, this e-operating Model can be applied. 2.3 Reading Roadmap The proposed reading Roadmap indicates the importance of each section to each party, since this document is focused on the various implementations that have to be performed. Nevertheless, reading of other sections contributes to a better global understanding of the EPC e-operating Model. Table 1 indicates the importance of each section to each party. Chapter Table 1: Proposed reading roadmap Creditor Routing Service Validatio n Service Directory Service Certification Authority 3. EPC e-operating Model Overview X X X X X 4. Implementation Guidelines 4.1 General requirements X X X X X 1 It is also intended for use with the B2B Scheme EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 11-9 April 2013

12 Chapter Creditor Routing Service Validatio n Service Directory Service Certification Authority 4.2 Debtor requirements X 4.3 Creditor requirements X 4.4 Routing Service Provider requirements X 4.5 Validation Service Provider requirements X 4.6 Directory Service requirements X 4.7 Certification Authority requirements X X X 5 Message specification 5.1 Notation Conventions X X X 5.2 EPC e-operating Model Messages eom-msg-cred-to-rs-001 X X eom-msg-rs-to-vs-001 X X eom-msg-vs-to-rs-001 X X eom-msg-rs-to-cred-001 X X eom-msg-cred-to-rs-002 X X eom-msg-rs-to-vs-002 X X eom-msg-vs-to-rs-002 X X eom-msg-rs-to-cred-002 X X 5.3 Error codes X X X Annex A - XML Schemas A.1 eom-common.xsd X X X A.2 eom-status.xsd X X X A.3 eom-msg-cred-to-rs-001.xsd X X A.4 eom-msg-rs-to-vs-001.xsd X X A.5 eom-msg-vs-to-rs-001.xsd X X A.6 eom-msg-rs-to-cred-001.xsd X X A.7 eom-msg-cred-to-rs-002.xsd X X A.8 eom-msg-rs-to-vs-002.xsd X X EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 12-9 April 2013

13 Chapter Creditor Routing Service Validatio n Service Directory Service Certification Authority A.9 eom-msg-vs-to-rs-002.xsd X X A.10 eom-msg-rs-to-cred-002.xsd X X Annex B - XML Message Samples B.1 eom-msg-cred-to-rs-001 X X B.2 eom-msg-rs-to-vs-001 X X B.3 eom-msg-vs-to-rs-001 X X B.4 Error eom-msg-vs-to-rs-001 X X B.5 eom-msg-rs-to-cred-001 X X B.6 Error eom-msg-rs-to-cred-001 X X B.7 eom-msg-cred-to-rs-002 X X B.8 eom-msg-rs-to-vs-002 X X B.9 eom-msg-vs-to-rs-002 X X B.10 Error eom-msg-vs-to-rs-002 X X B.11 eom-msg-rs-to-cred-002 X X B.12 Error eom-msg-rs-to-cred-002 X X Annex C Recommended Strategies for BIC Resolutions Annex D Certificate Enrolment Requirements X X D.1 Authentication Certificate for Routing Service providers X X D.2 Authentication Certificate for Validation Service providers D.3 Signing Certificate for Validation Service providers Annex E. X.509 Certificate Profiles X X X X E.1 Routing Service authentication certificate profile E.2 Validation Service authentication certificate profile X X X X X X E.3 Signing certificate profile X X X X EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 13-9 April 2013

14 3 EPC E-OPERATING MODEL OVERVIEW 3.1 Four Corner Model The e-mandates conceptual model is based on the Four Corner Model of the SDD Scheme, which introduces two new entities: the Routing Service and the Validation Service. Figure 1: e-mandate Conceptual Four Corner Model To implement the e-mandate conceptual model a technical standard has been designed: the EPC e- Operating Model. 3.2 Scope The EPC e-operating Model covers exclusively the application data transport over the Internet between the Creditor Websites and Validation Services making use of Routing Services. The messages described on the e-operating Model will envelop the ISO XML e-mandate messages 2. The interactions between the Debtor and the Creditor (to the exception of TLS usage in the connections) and the Debtor and the Online Banking / Validation Service are out of scope of this specification. In particular, the means of authentication used by Validation Service to authenticate the Debtor are at the sole discretion of the underlying Debtor Bank. This document only describes the process flow. The liabilities and responsibilities of each party are described in [3] and [4]. 2 For the sake of simplicity, the terms e-mandate and e-mandate request/proposal will be used throughout this document to refer to the e-operating Model messages enveloping the ISO XML e-mandate messages. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 14-9 April 2013

15 The accommodation of the requirements of this specification to particular contexts, environments, architectures or infrastructures is also outside the scope of this specification. Implementing parties must guarantee the deployment of the requirements in such a way as to maintain the overall security, availability and interoperability, applying the best known practices to additional particular procedures and processes. 3.3 e-operating Model Parties The execution of the e-mandate service, complementing the SEPA Direct Debit Scheme, involves the following main parties: Debtor: gives the Mandate to the Creditor to initiate Collections. The Debtor s bank account is debited in accordance with the Collections initiated by the Creditor. By definition, the Debtor is always the holder of the account to be debited [2] Creditor: receives the Mandate from the Debtor to initiate Collections, which are instructions to receive Funds from the Debtor Bank by debiting the account of the Debtor. On the basis of this Mandate, the Creditor collects the direct debits [2] Creditor Bank: is the bank where the Creditor's account is held and which has concluded an agreement with the Creditor about the rules and conditions of a product based on the Scheme. On the basis of this agreement, it receives and executes instructions from the Creditor to initiate the Direct Debit Transaction by forwarding the Collection to the Debtor Bank in accordance with the Rulebook. [2] Debtor Bank: is the bank where the account to be debited is held and which has concluded an agreement with the Debtor about the rules and conditions of a product based on the Scheme. On the basis of this agreement, it executes each Collection of the direct debit originated by the Creditor by debiting the Debtor s account, in accordance with the Rulebook. [2] Routing Service: Providers offer this service, in agreement with and on behalf of Creditor Banks, for giving access, by Creditors, to validation services made available by Debtor Banks for the validation of e-mandates initiated by Debtors through the electronic channels of Creditors. Creditor Banks may provide these routing services themselves. [3] Validation Service: Providers offer this service in agreement with and on behalf of Debtor Banks for validation of e-mandate proposals initiated by Debtors through the electronic channels of Creditors and the routing services offered by Creditor Banks. Debtor Banks may provide these validation services themselves. [3] In order for the e-operating Model to fulfil the reachability and security requirements, it is necessary to consider two new parties: the Directory Service providers and the EPC Approved Certification Authorities. Directory Service: Providers offer this service in agreement with a Routing Service Provider to enable reachability to all participant Banks with the role of Debtor Bank. The directory must have an update list of all participant Debtor Banks operational BICs and the correspondent Validation Service URLs. Approved Certification Authorities: PKI Certification Authorities (CAs) that issue certificates for Validation Service providers and Routing Service providers, with extensions that qualify the entities as legitimate Validation Service providers or Routing Service providers. These CAs must present a Declaration of Compliance to the EPC. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 15-9 April 2013

16 3.4 Principles The e-operating Model is based on the following principles, as stated in the e-mandates EPC e- Operating Model - High-level Definition [10]: It is not mandatory for Debtors to use this service, when offered by the Debtor Bank; The Debtor must have a commercial agreement with a Creditor and the Creditor must give access to his Website; The Debtor must have access to the Online Banking service provided by the Debtor Bank; The Debtor s Bank and the Debtor must have an agreement on the conditions for using the means of authentication; The Creditor and the Creditor s Bank must have an agreement on the conditions for using the Routing Service(s) providers; In order to participate, Routing Services must be accredited by Creditor Banks; The Creditor Bank must designate one or more Routing Service providers and must have an agreement with each one on the conditions of use; In order to participate, Validation Services must be accredited by Debtor Banks; The Validation Service will always respond to the Routing Service from which the enquiry was originated. The parties defined in the model can be provided by one or more entities, assuming that segregation measurers are in place. Each party is allowed to create additional features on top of the model as long as the interoperability is not affected. The Validation Service electronically signs the e-operating Model enveloped message, on behalf of the Debtor if the authentication / authorization means are correctly used. For technical purposes, the following additional principles are considered: In order to participate, Creditors must enrol with a Routing Service acting on-behalf of the Creditor Bank; All Routing Services must be able to connect with all e-mandate Validation Services; A Routing Service must be able to connect at least to one Directory Service. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 16-9 April 2013

17 3.5 Model Description Figure 2: e-operating Model The Debtor accesses the Creditor s Website (flow 1, in Figure 2) using the browser for the completion of the Debtor Information by entering all the required elements (including the Operational BIC). Afterwards, the Creditor s Website creates the e-mandate proposal by adding the Creditor Information to the Debtor Information and submits the e-mandate proposal to a Routing Service (flow 2). In order to identify the Validation Service URL, the Routing Service queries a Directory Service using the provided Operational BIC. Using the Validation Service URL of the Debtor Bank, the Routing Service submits the e-mandate proposal (flow 3) to the Validation Service. The mutual authentication between the Routing Service and the Validation Service is achieved by using certificates issued by EPC Approved Certification Authorities. The Validation Service performs the validation of the BIC, IBAN and account access. The Debtor is routed from the Creditor s Website to the Validation Service of the Debtor Bank (flow 4) for the authentication of the Debtor. Alternatively, the Validation Service may assign a unique proposal reference and transmit it through the Routing Service to the Creditor to display it to the Debtor on the website. The Debtor may resume the operation on the Validation Service at a later time by using that reference. At the Validation Service, the Debtor must identify and authenticate (flow 5) himself according to the instructions received from the Debtor Bank. The Debtor Bank defines and provides the authentication means that the Debtors should use. If multiple authorizations are required for a given account (a typical B2B scenario), the Debtor Bank must gather enough authorizations from the other account holders. After a successful authentication, the Debtor Bank confirms (flow 6) the result to the Debtor and returns the e-mandate to the Creditor through the intermediary of the initial Routing Service (flows 7 and 8). The mutual authentication between the Routing Service and the Validation Service is achieved by using certificates issued by EPC Approved Certification Authorities. The Debtor is routed back to the Creditor s Website which acknowledges the receipt of the e- Mandate and confirms this to the Debtor (flow 9). EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 17-9 April 2013

18 This model applies for all three operations: issuance, amendment and cancellation of e-mandates. 3.6 Message flows In order to implement the e-operating Model, it is necessary to describe message flows between the four parties: the Debtor s Browser (used by the Debtor), the Creditor s Website, the Routing Service and the Validation Service. Two possible message flows are defined: the Single Authorization Message Flow (SAMF) that is applicable when just a single authorization from an account holder is needed to issue an e-mandate. This message flow is described in section the Multiple Authorization Message Flow (MAMF) that is applicable when authorizations from n different account holders are needed to issue an e-mandate (a typical B2B scenario and therefore not for inclusion in the Core Scheme). This message flow may also be used when n = 1 in the following example scenarios: o automatic redirects from the Creditor Website to the Validation Service are undesirable. o the Debtor is to be given the opportunity to authorize the e-mandate at a later time (he may not have all its access credentials at the moment). This message flow is described in section EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 18-9 April 2013

19 3.6.1 Single Authorization Message Flow The several interactions for the Single Authorization Message Flow are illustrated in Figure 3. Figure 3: Simple Authorization Message Flow The message flow is described on Table 2 and applies to all available e-mandate operations (issuing, amendment and cancellation). EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 19-9 April 2013

20 Table 2: Single Authorization Message Flow description Step Action Service Description Reference Data / Message 1 The Debtor using an Internet Browser accesses the Creditor s Website. The Debtor must validate that the presented Creditor Information is correct (Creditor Name, Address, etc) and mandatory legal wording are shown. The Debtor selects the transaction (issuing, amendment or cancellation) and the Creditor s Website presents a form to collect the Debtor s information required for the transaction (e.g. operational BIC of the Debtor s Bank for an e-mandate issuance). The Website may already have some Debtor information stored and pre-fill some of the fields. 1. Initiation Debtor Info Using the information provided by the Debtor, the Creditor s Website merges the Debtor data with the required Creditor information to generate the e-mandate proposal message. Regardless of the information that is transported for the e-mandate service, the BIC is a mandatory field for the routing of the message. 2 The Creditor s Website URL (CWS URL) must also be included to redirect the Debtor back to the Creditor at a later stage (step 16) along with the exact date and time limit for the whole transaction to be finished before it will be discarded (in the absence of a value, a default 15 minutes timeout must be considered). 2. Mandate Request eom-msg- cred-to-rs- 001 The message, along with the CWS URL, is submitted to the Routing Service using the URL and credentials provided by the Creditor Bank (issued by the Routing Service Provider) or directly by the Routing Service Provider. Creditor credentials may include a certificate, username/password or other secure means provided by the Routing Service. After verifying the Creditor s credentials, the Routing Service receives the e-mandate proposal message and validates that all the required fields are filled-in. 3 The Routing Service then looks up the Directory Service (either an online request or a cached mapping) to resolve the Operational BIC into the Validation Service URL. The Directory Service provider may request the use of authentication credentials. The Directory Service provider may request the use of authentication credentials. BIC (input), Validation Service URL The Directory Service returns the Validation Service URL for the provided Operational BIC. 4 The Routing Service dispatches the received request to the Validation Service URL indicating that this is an e-mandate enrolment request. The Routing Service must present a client certificate issued by an EPC approved CA qualifying it as legitimate Routing Service and the Validation Service must present a server certificate issued by an EPC approved CA qualifying it as a legitimate Validation Service (see section 3.8). 3. Mandate Request eom-msg-rsto-vs The Validation Service validates the e-mandate proposal and stores the information. e-mandate proposal, optype, CWS URL EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 20-9 April 2013

21 Step Action Service Description Reference Data / Message 6 The Validation Service returns a status code (OK) and a URL specific to this transaction (VS URL), which will be used on step 8/9 to redirect the Debtor s browser. eom-msg-vsto-rs The Validation Service response is returned to the Creditor s Website. 8, 9 The Creditor, which is still holding the control of the Debtor s browser, performs a redirect to the given Validation Service URL. VS URL 10 The Debtor is redirected from the Creditor s Website to an authentication screen offered by the Validation Service to the Debtor, in order to authenticate the Debtor. 4. Request authentication means Authentication form 11 The Debtor enters the authentication credentials agreed with the Debtor Bank The authentication credentials may be composed of personalised device(s) and/or a set of procedures, including its personalized security features ([1] PT-07.03). Authentication data 12 The Validation Service verifies the provided authentication credentials. Authentication data 13 If the authentication credentials provided are correct and valid, the Validation Service presents an authorization form along with all the mandate data and mandatory legal wording. The Validation Service will collect the IBAN from the Debtor and any other relevant information for Debtor Banks. The Validation Service can present the accounts for which he is the holder and has direct debit rights. mandate info, authorization form 14 The Debtor is asked to verify the mandate data (e.g., the accuracy of the Creditor information, for example, name and address) and proceeds with the authorization. The authorization is defined here as the set of procedures agreed between the Debtor and the Debtor Bank to assure the clear consent of the Debtor for the issuing, amendment and cancellation of an e-mandate. 5. Authorization Authorization data 15 The Validation Service verifies the authorization and performs an electronic signature of the e-mandate data on the envelop message. e-mandate (input), electronically signed e- mandate (output) 16 The Validation Service presents a confirmation message to the Debtor along with the e-mandate data and a link to the Creditor s Website (URL provided on step 4) 6. Confirmation mandate info, CWS URL 17 The Debtor follows the link to the Creditor s Website. CWS URL 18 The Creditor s Website recovers the e-mandate transaction data and sends a request with the e-mandate request identifier to the arranged Routing Service in order to retrieve the issued e-mandate. The Creditor must present the credentials previously arranged with the Routing Service provider (similar to step 2). eom-msg-rsto-cred-001 eom-msg- cred-to-rs- 002 EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 21-9 April 2013

22 Step Action Service Description Reference Data / Message 19 The Routing Service dispatches the e-mandate retrieving request to the same Validation Service URL resolved in step 3, indicating that this is a retrieval operation. The Routing Service must present a client certificate issued by an EPC approved CA qualifying it as legitimate Routing Service and the Validation Service must present a server certificate issued by an EPC approved CA qualifying it as a legitimate Validation Service (see section 3.8). eom-msg-rsto-vs The Validation Service returns the electronically signed enveloped message of the e-mandate to the Routing Service. 7. e-mandate eom-msg-vsto-rs The Routing Service performs an electronic signature validation of the enveloped e-mandate received. e-signed mandate 22 The Routing Service returns the electronically signed e-mandate enveloped message to the Creditor s Website. The Creditor may perform a validation of the e-mandate enveloped message electronic signature received or rely on the verification previously performed by the Routing Service. 8. e-mandate eom-msg-rsto-cred The Creditor acknowledges the reception of the e-mandate. eom-msg- cred-to-rs The Creditor s Website presents a confirmation message along with the e- Mandate data to the Debtor. The Creditor stores the electronically signed e-mandate XML file according to national legal requirements. 9. Confirmation mandate info 25 The Routing Service forwards the acknowledgment of the reception of the e-mandate to the Validation Service. eom-msg-rsto-vs-002 The data sets exchanged in each of the steps are the same for all the operations defined for e- Mandates: issuance, amendment and cancellation. However, some of the optional fields defined in the e-mandate request message (DS-12, [3]; [11]) and the e-mandate validation message (DS-13, [3]; [11]) may be required for some of the operations Multiple Authorizations Message Flow (Only applicable in the B2B Scheme) The several interactions for the Multiple Authorizations Message Flow are illustrated in Figure 4. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 22-9 April 2013

23 Figure 4: Multiple Authorizations Message Flow The message flow is described on Table 3 and applies to all available e-mandate operations (issuing, amendment and cancellation). EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 23-9 April 2013

24 Table 3: Multiple Authorizations Message Flow description Step Action Service Description Reference Data / Message 1 The Debtor using an Internet Browser accesses the Creditor s Website. The Debtor must validate that the presented Creditor Information is correct (Creditor Name, Address, etc) and mandatory legal wording are shown. The Debtor selects the transaction (issuing, amendment or cancellation) and the Creditor s Website presents a form to collect the Debtor s information required for the transaction (e.g. operational BIC of the Debtor s Bank for an e-mandate issuance). The Website may already have some Debtor information stored and pre-fill some of the fields. 1. Initiation Debtor Info Using the information provided by the Debtor, the Creditor s Website merges the Debtor data with the required Creditor information to generate the e-mandate proposal message. Regardless of the information that is transported for the e-mandate service, the BIC is a mandatory field for the routing of the message. 2 The Creditor s Website URL (CWS URL) must also be included to redirect the Debtor back to the Creditor at a later stage (step 16) along with the exact date and time limit for the whole transaction to be finished before it will be discarded (in the absence of a value, a default 48 hours timeout must be considered ). 2. Mandate Request eom-msg- cred-to-rs- 001 The message, along with the CWS URL, is submitted to the Routing Service using the URL and credentials provided by the Creditor Bank (issued by the Routing Service Provider) or directly by the Routing Service Provider. Creditor credentials may include a certificate, username/password or other secure means provided by the Routing Service. After verifying the Creditor s credentials, the Routing Service receives the e-mandate proposal message and validates that all the required fields are filled-in. 3 The Routing Service then looks up the Directory Service (either an online request or a cached mapping) to resolve the Operational BIC into the Validation Service URL. The Directory Service provider may request the use of authentication credentials. The Directory Service provider may request the use of authentication credentials. BIC (input), Validation Service URL The Directory Service returns the Validation Service URL for the provided Operational BIC. 4 The Routing Service dispatches the received request to the Validation Service URL indicating that this is an e-mandate enrolment request. The Routing Service must present a client certificate issued by an EPC approved CA qualifying it as legitimate Routing Service and the Validation Service must present a server certificate issued by an EPC approved CA qualifying it as a legitimate Validation Service (see section 3.8). 3. Mandate Request eom-msg-rsto-vs The Validation Service validates the e-mandate proposal and stores the information. e-mandate proposal, optype, CWS URL EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 24-9 April 2013

25 Step Action Service Description Reference Data / Message 6 The Validation Service returns a status code (OK) and an identifier code specific to this transaction (VS mandate ID), which will be used by the Debtor later on step 14. eom-msg-vsto-rs The Validation Service response is returned to the Creditor s Website. eom-msg-rsto-cred The Creditor, which is still holding the control of the Debtor s browser, displays the VS proposal reference to the Debtor. VS proposal ref 9 3 The account holder goes to the Validation Service authentication URL. VS auth URL 10 The account holder is presented with an authentication screen offered by the Validation Service asking for the authentication credentials. 4. Request authentication means Authentication form 11 The account holder enters the authentication credentials agreed with the Debtor Bank. The authentication credentials may be composed of personalised device(s) and/or a set of procedures, including its personalized security features ([1] PT-07.03). Authentication data 12 The Validation Service verifies the provided authentication credentials. Authentication data 13 If the authentication credentials provided are correct and valid, the Validation Service asks the account holder to select the e-mandate request to be authorized. This may be performed by having an input field to enter the VS proposal reference presented in step 8 or a select list from which the account holder can choose one of the pending e-mandate requests. [proposals list] 14 The account holder selects the e-mandate request to be authorized. VS proposal ref 15 The Validation Service presents an authorization form along with all the mandate data and mandatory legal wording. The account holder is asked to verify the mandate data (e.g., the accuracy of the Creditor information, for example, name and address). 5. Authorization Authorization data 16 The account holder verifies the mandate data and proceeds with the authorization. The authorization is defined here as the set of procedures agreed between the Debtor and the Debtor Bank to assure the clear consent of the Debtor for the issuing, amendment and cancellation of an e-mandate. mandate info, authorization form 17 The Validation Service verifies the authorization and performs an electronic signature of the e-mandate data on the envelop message. e-mandate (input), electronically signed e- mandate (output) 3 If multiple authorizations are required for that account (a typical B2B scenario), the Debtor Bank must gather enough authorizations from the other account holders, by repeating steps 9 through 16 (loop). EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 25-9 April 2013

26 Step Action Service Description Reference Data / Message 18 The Validation Service presents a confirmation message to the Debtor along with the e-mandate data and a link to the Creditor s Website (URL provided on step 4) 6. Confirmation mandate info, CWS URL 19 The Debtor follows the link to the Creditor s Website. CWS URL 20 The Creditor s Website recovers the e-mandate transaction data and sends a request with the e-mandate request identifier to the arranged Routing Service in order to retrieve the issued e-mandate. The Creditor must present the credentials previously arranged with the Routing Service provider (similar to step 2). eom-msg- cred-to-rs The Routing Service dispatches the e-mandate retrieving request to the same Validation Service URL resolved in step 3, indicating that this is a retrieval operation. The Routing Service must present a client certificate issued by an EPC approved CA qualifying it as legitimate Routing Service and the Validation Service must present a server certificate issued by an EPC approved CA qualifying it as a legitimate Validation Service (see section 3.8). eom-msg-rsto-vs The Validation Service returns the electronically signed enveloped message of the e-mandate to the Routing Service. 7. e-mandate eom-msg-vsto-rs The Routing Service performs an electronic signature validation of the enveloped e-mandate received. e-signed mandate 24 The Routing Service returns the electronically signed e-mandate enveloped message to the Creditor s Website. The Creditor may perform a validation of the e-mandate enveloped message electronic signature received or rely on the verification previously performed by the Routing Service. 8. e-mandate eom-msg-rsto-cred The Creditor acknowledges the reception of the e-mandate. eom-msg- cred-to-rs The Creditor s Website presents a confirmation message along with the e- Mandate data to the Debtor. The Creditor stores the electronically signed e-mandate XML file according to national legal requirements. 9. Confirmation mandate info 27 The Routing Service forwards the acknowledgment of the reception of the e-mandate to the Validation Service. eom-msg-rsto-vs-002 The data sets exchanged in each of the steps are the same for all the operations defined for e- Mandates: issuance, amendment and cancellation. However, some of the optional fields defined in the e-mandate request message (DS-12, [3]; [11]) and the e-mandate validation message (DS-13, [3]; [11]) may be required for some of the operations. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 26-9 April 2013

27 3.7 Security The e-operating Model design is intended for Internet use, meaning that the interactions between the different parties take place across interlinked public networks. These networks have been subject to a great number and variety of threats during the past years. Banking and e-commerce services provided on the Internet have been specially targeted in recent years given the potential financial benefits that can be gained by the perpetrators. Entities providing these services have been able to adapt and counter these attacks. The e-operating Model interconnects a vast number and variety of parties and therefore the capability to respond to threats are unavoidably cumbersome. Thus, the security requirements for this model are raised to a level as to minimize the needs for change when confronted with new threats. The security mechanisms hereby presented are at two levels: the transport level (section 3.7.1) and the application level (section 3.7.2). The Certification Authorities are the key enablers for those mechanisms (section 3.7.3). Although the Debtor authentication through the Validation Service is out of scope, the overall risk level of the e-operating Model still strongly depends on the security measures adopted in those interactions between the Validation Service and the Debtor. The adoption of authentication methods aligned with industry best practices, as found in the EPC document Customer-to-Bank Security Good Practices Guide [9] complements the overall security model Transport Level Security The first step towards a secure model is to protect the exchanged data on a host-to-host connection by creating a secure networking channel. This can be achieved by using the TLS protocol [22], which has standard built-in mechanisms to provide: Authentication of parties, based on X.509 certificates. The server is always authenticated whereas the client may optionally be authenticated (mutual authentication); Confidentiality of data, by performing a symmetric key agreement at session initiation and using that key to cipher the exchanged data. The risk of eavesdropping is mitigated; Data Integrity, based on cryptographic hash functions. The risk of tampering is mitigated. The EPC e-operating model enforces the use of TLS on all connections between Debtors and Creditors, Creditors and Routing Services, Routing Services and Directory Services and Routing Services and Validation Services. The connections between Debtors and Validation Services/Online Banking of Debtor Banks are outside the scope of the EPC e-operating Model. The mutual authentication feature of TLS is required between the Routing Services and Validation Services, in order to allow only legitimate Routing Services to access legitimate Validation Services. Due to the absence of a direct contractual relationship between those parties, it is expectable that Routing Services and Validation Services may not know each other prior to the first connection establishment. Therefore, a secure and interoperable mechanism is necessary to allow Routing Services to be able to recognize Validation Services as being SEPA enrolled and legitimate and, reversely, Validation Services to be able to recognize Routing Services as being SEPA enrolled and legitimate. This objective is accomplished by restricting the set of approved issuing Certification Authorities and by using specific certificate extensions that qualifies the entitled entities as being legitimate participants (Routing Services or Validation Services). The issuing Certification Authority is responsible to comply with the full set of procedures defined in the EPC e-operating Model which are required for the enrolment of Routing Service and Validation Service providers. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 27-9 April 2013

28 When establishing a TLS session, the authentication is performed during the handshake. When the parties present each other their certificates, a verification of the presented certificates must be performed. The certificate verification must follow the general rules described on the RFC 5280 [23], and, if applicable to the certificates presented, an additional step to verify the existence of the EPC e-operating Model specific policy. The most significant steps of the process are illustrated on Figure 5. Figure 5: Significant steps of the certificate verification The minimum version of TLS to be supported is 1.0, but all parties are recommended to migrate to TLS v1.2 as soon as possible (for interoperability purposes, all versions of TLS have mechanisms to provide both forward and backward compatibility) Application level security The security measures discussed in Section are focused on the transport level, providing network security on a host-to-host basis. Additional complimentary measures must be addressed to further increase the overall security of the e-operating Model. Those measures are targeted to the application level and include: Electronic signatures, described in Section ; Time accuracy, described in Section ; Audit trails, described in Section ;Error reporting, described in Section ; Timeouts, described in Section ; Caching of BIC resolutions, described in Section EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 28-9 April 2013

29 Electronic signatures The most important security measure at the application level is the binding of electronic signatures 4 to e-mandates by Validation Services. Electronic signatures are based on common cryptographic techniques and are efficient and highly secure mechanisms that provide the following security properties [16] at the application level: Authenticity a party receiving an electronically signed e-mandate is able to positively confirm the identity claimed by the source of the e-mandate. Integrity - verification of the completeness and accuracy of an e-mandate. Non-Repudiation - ability to prove that the issuance of an e-mandate has taken place, so that it can not be repudiated later in support of a dispute resolution. Since the e-mandate is a XML electronic document, the format of the electronic signature will be in accordance with XML Advanced Electronic Signatures (XAdES) [31], in the form of Basic Electronic Signatures (XAdES-BES). The profiles defined for XAdES-BES [32] are compliant with the requirements of the European Directive 1999/93/EC [34] for Advanced Electronic Signatures 5, while being also fully compatible and interoperable with legacy implementations of the plain W3C specification XML Signature [25] (from which XAdES derives). The electronic signature will be applied as an enveloping signature. The original XML content of the e-mandate remains unchanged and is encapsulated into a secure XML case ( Figure 6). Figure 6: Enveloping XML signature The electronic signature verification is composed of a verification of the signing certificate followed by a cryptographic verification of the electronic signature (see Figure 5). This process is depicted in Figure 7. Figure 7: Electronic signature verification 4 Electronic Signature is a concept introduced by the European Directive 1999/93/EC [34]. It is also commonly referred as Digital Signature, as defined in ISO : See also document Impact of the EESSI Standards on the European Banking Community (SPTF-029/05) [8]. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 29-9 April 2013

30 The electronic signature verification of e-mandates must be performed by Creditors and Routing Services. However, due to the complexity of the verification process and given the contractual nature of the relationship between Creditors and Routing Services, Creditors may delegate the responsibility of the verification to the relying Routing Service provider Time accuracy Each party of the model should have its system clocks synchronized with a trusted time source of its choice. This guarantees a reasonable timeliness of data and operations between several different parties and the accuracy of exchanged times and dates (e.g., field AT-25 [3], [4]) Audit trails Routing Service and Validation Service providers must produce audit trails on their systems for all relevant operations, including the initialization of the audit trail, issuance, amendment and cancellation of e-mandates, configuration changes, access attempts, exceptions and key management functions critical to the security of the reliance being placed on PKI processes and operations. The audit trails can be applicational logs or other equivalent means of evidence, as long they contain sufficient information to trace back the complete details of an operation and can be searched or queried in an automated way. The audit trails must be stored in a long-term support and a tamper evident format, such that illicit addition, modification or deletion of any audit trail can be detected. The dates and times registered in the audit trails must be obtained from a trusted time source to ensure accuracy and a reasonable clock synchronization of the different parties (see section ). Annex C of CWA [27] presents guidelines for the implementation of a Signature Logging Component Error reporting To avoid unpredictable and/or ad-hoc operation results on abnormal situations, error messages are defined to report incidents. Having well-known error messages has the following advantages: Handling of errors can be improved since all possible cases are known in advance The strict formatting of error messages avoids accidental disclosure of sensitive details (e.g., infrastructure details) Timeouts The services running over the EPC e-operating Model are usually composed of several steps. In each of them, the requests may be in a holding state, waiting for some event, be it input or the occurrence of a given action. During this time, resources are consumed to maintain the context of the state. If the event does not occur, the systems may end up with too many exhausted resources resulting from aborted requests. Therefore, adequate timeout mechanisms must be implemented to invalidate endless requests and free up the committed resources. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 30-9 April 2013

31 Caching of BIC resolutions In order to contact the corresponding Validation Services, the Routing Service providers must be able to resolve BICs into Validation Service URLs. This is achieved by using a Directory Service that maps the Debtor s Bank Operational BICs into the designated Validation Service URLs. If the Directory Service is queried for each incoming transaction and the Routing Service provider is fully dependent on the response to proceed with the transaction, the Directory Service would be a single point of failure. This means that an interruption (either accidental or deliberate) of the Directory Service can make the whole system unavailable, since Routing Services will not be able to route the requests. One important mechanism to mitigate this risk is to cache the BIC resolutions. Routing Services are recommended to maintain an internal mapping of the BICs and respective Validation Service URLs. The e-operating Model suggests three approaches to build the cache: 1. Request the Directory Service for the full mapping table and store it locally; 2. Request the changes occurring between a previous version and the current table; 3. Collect and cache the queries as they are being processed. Regardless of the implementation, cached results must not be used longer than 30 days to assure that any mapping changes and new additions or deletions are reflected in a predictable period of time Public Key Infrastructure Some of the identified mechanisms in the above sections make use of certificates, either for TLS or for electronic signatures. Therefore, a Public Key Infrastructure (PKI) is needed not only to issue the certificates, but to manage their lifecycle (suspensions, revocations and reactivations) and provide additional services (e.g., CRL, OCSP, etc.) as well. Since the EPC e-operating Model is to be run by heterogeneous entities, both in nature and interests, it is desirable to allow some flexibility in the choice of the Certification Authority (CA) from which to request the certificates. Nonetheless, it is fundamental to create mutual trust and recognition between players operating cross border in the SEPA environment. This trustable set of CAs is defined by the EPC by accepting candidate CAs that declare strict compliance with the rules of enrolment and certification practices defined in the EPC e-operating Model and are sponsored by a Routing Service or Validation Service provider. Applicant CAs may be already established in the market, private internal CAs in use by the parties or special purpose CAs specifically targeted to the EPC e-operating Model. In either of the cases, the conditions for application to the EPC are a sponsorship of a Routing Service or Validation Service provider and full compliance with the defined rules for Certification Authorities. The adoption of the required certification practices minimizes the risk of compromise of a CA, while the enrolment rules guarantees the univocal identity and legitimacy of the end entity. Once a CA is approved by the EPC, it becomes part of the EPC Approved CAs set and must be trusted by all participating parties that need SEPA certificates (i.e., Routing Service and Validation Service providers). This common set of trust anchors is the basis for the interoperability between Routing Services and Validation Services, which may not know each other prior to a transaction. Besides the EPC Approved CAs, the following additional categories of CAs are also considered in the e-operating Model: EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 31-9 April 2013

32 Commercial Certification Authorities are current market established CAs, generally trusted by browsers and server frameworks. Interoperability of certificates issued by these CAs is out of the scope of this e-operating model; Routing Service CA is a CA that issues TLS client certificates for Creditors by request of the Routing Service. This provides stronger authentication of Creditors for the Routing Service. The Routing Service CA can be a commercial available CA for which the Routing Service settles an agreement or a self-owned specific purpose CA. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 32-9 April 2013

33 The full set of certificates necessary for the e-operating Model is illustrated in Figure 8. Figure 8: PKI and certificates for the e-operating model Table 4 presents a description of the certificates depicted in Figure 8. Table 4: Description of the e-operating Model certificates Ref Certificate Type CA Authenticated Object Verifying Party Description 1 TLS Server Commercial Creditor Debtor Authenticates the Creditor to the Debtor. Protects the communication between these two parties. 2 TLS Server Commercial / EPC approved Routing Service Creditor Authenticates the Routing Service to the Creditor. Protects the communication between these two parties. 3 TLS Client Routing Service / Commercial Creditor Routing Service (Optional) Authenticates the Creditor to the Routing Service. 4 TLS Server EPC approved Validation Service Routing Service Authenticates the Validation Service to the Routing Service. This certificate is specific for the Validation Services of the e-operating Model. Protects the communication between these two parties. 5 TLS Client EPC approved Routing Service Validation Service Authenticates the Routing Service to the Validation Service. This certificate is specific for the Routing Service of the e-operating Model. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 33-9 April 2013

34 Ref Certificate Type CA Authenticated Object Verifying Party Description 6 Signing EPC approved Validation Service e-mandate Creditor, Routing Service Signs messages in the e-operating Model through the use of a specific certificate for this purpose. 7 TLS Server Commercial Directory Service Routing Service Authenticates the Directory Service to the Routing Service. Protects the communication between these two parties. The profiles for the certificates to be issued by EPC approved Certification Authorities are detailed in Annex E. The profile specified on the e-operating Model for certificate 5 (Routing Service TLS Client) allows Routing Services to use it simultaneously as certificate 2, as it will also be ready for serverside usage. 3.8 Routing and interoperability According to the message flow described on section 3.6, Routing Service providers are responsible for delivering the messages exchanged between Creditors and Validation Service providers. Therefore, Routing Service providers must be able to connect to every Validation Service provider available. In order to do so, the following conditions must be met by the Routing Service: 1. The URL address of the target Validation Service must be known; 2. The Validation Service must be authenticated as a legitimate one; 3. Must provide credentials so that the Validation Service can be guaranteed that it is a legitimate Routing Service provider. Condition 1 is achieved by resolving the BIC into the Validation Service provider URL using the Directory Service. This information complements the already existing market offer of BIC Directory services that namely provide routing information for SEPA payments. The existing providers may complement their service offer with the additional information of the Validation Service address (e.g. URL) for any operational BIC. Providers that offer this enhanced BIC Directory service to Routing Service Providers will facilitate reachability to the Validation Services of Debtor Banks. For this purpose, the directory must have an updated list of all participant Debtor Banks operational BICs and the correspondent Validation Service URLs. The Directory Service providers must maintain an updated mapping of the operational BICs of the e-mandates Debtor Banks and the corresponding Validation Service URLs. These URLs are the Validation Service entry points for the EPC e-operating Model to be used by Routing Services Each Routing Service can then choose to use either a service provider for BIC Directory (option a ) or download the information directly from the EPC website (option b ), depicted on Figure 9. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 34-9 April 2013

35 Debtor Browser 9. Confirmation 1. Initiation Creditor Website Directory 4. Request Authentication Means 5. Authorization 6. Confirmation 2. Mandate Request 8. e-mandate EPC SEPA Directory b) Validation Service 3. Mandate Request 7. e-mandate Routing Service a) BIC Directory Service Provider Debtor Bank Creditor Bank Figure 9: e-operating Model - options for Directory Services. Condition 2 is achieved by using exclusive Validation Service authentication certificates and condition 3 is achieved by using exclusive Routing Service authentication certificates. These two types of certificates, described on section 3.7.3, are used to establish secure HTTP connections over TLS. Both parties taking place on such a session must validate the presented certificates similarly as described in section EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 35-9 April 2013

36 4 IMPLEMENTATION GUIDELINES 4.1 General requirements The baseline requirements that are generic to all entities are presented in this section Networking The e-operating Model runs over the standard networking stack TCP/IP, widely used on the Internet. Parties must use standard TCP ports, namely port 80 for HTTP and 443 for HTTPS. At the application layer, data must be exchanged over HTTP version 1.1. For all HTTP responses whose content is an XML message, the Content-Type header must be set to the MIME type text/xml Internationalisation Parties must use UTF-8 as the character set for the data exchanged. UTF-8 supports all characters of European languages, thus improving interoperability. Due to the international nature of SEPA, parties are recommended to provide Debtors with localized interfaces. This means to have not only translated text, but also properly formatted currency and date values, support for time zones and legal and regulatory compliance Time accuracy Creditors, Routing Services, Validation Services and Directory Services are recommended to keep their system clocks synchronized with a trusted time source of their choice. As a reference, if the NTP protocol is used, stratum 3 is the minimum acceptable level. Certification Authorities are subject to specific time accuracy restrictions described in CWA [28] and TS [30]. The time information exchanged must be always related to UTC Processing time The total transaction time to request an e-mandate should be acceptable to the Debtor, providing a fluid and responsive user experience. Parties must be aware that the Debtor will be guided through several different screens and, at the Validation Service/Online Banking, will be authenticated through specific means that can greatly extend the total transaction time Certificate Verification The X.509 certificates issued by EPC approved Certificate Authorities must be verified by a relying party according to the general rules defined in RFC 5280 [23]. The most significant steps of the process are illustrated on Figure 10. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 36-9 April 2013

37 Figure 10: Significant steps of the certificate verification The presented certificate must comply with the expected profile as defined in Annex E. In particular, the existence of the expected certificate policy identifiers must be verified, as well as the subject alternative name(s), if applicable. The certificate validity dates must be verified to guarantee that: 1. Not Before date is sooner than the actual validation date, meaning that the certificate is already valid; and 2. Not After date is later than the actual validation date, meaning that the certificate is not already expired. A trusted certificate chain must also be built in order to consider the presented certificate as trustful by completing a process known as Certification Path Validation. A certificate chain is a sequence of certificates where each certificate is signed by the next certificate in the chain. The chain starts with the presented certificate and ends with a self-signed certificate the root CA certificate. In the case of the EPC e-operating Model, the root CA must be part of the EPC approved CAs in order for the certificate to be considered trustful. The certificate chain is considered to be trustful only when: 1. It is correctly constructed and terminates in a trusted self-signed certificate from one of the EPC approved CAs, and 2. Each of its belonging certificates is also successfully verified. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 37-9 April 2013

38 Section 6 Certification Path Validation of RFC 5280 [23] presents a comprehensive description of this process along with the recommended processing rules. Finally, the revocation status must be checked for all certificates belonging to the certificate chain. In order to do that, each certificate is verified against its corresponding OCSP server [18] (URL obtained from the Authority Information Access extension) or the available online CRL [23] (URL obtained from the CRL Distribution Point extension). The use of OCSP is recommended as the primary source for checking revocation status. To increase the performance and scalability, OCSP responses may be cached for a maximum period of 24 hours. CRLs are recommended to be used as a fallback mechanism when the OCSP server is unavailable. If the revocation status verification can not be perfomed for example, due to unavailability of both the OCSP and CRL, the e-mandate must be rejected. 4.2 Debtor requirements In order to become eligible to use the e-mandates service, the Debtor must have established a contractual agreement with the Debtor Bank, allowing him to be the holder of an account with the following characteristics: Have permissions to use and manage direct debit services and e-mandates; Have access to the account services via the electronic channels supplied by the Debtor Bank. Parties interacting directly with Debtors may expect the existence of an Internet broadband connection 6 and a web browser compliant with the following requirements: HTML 4.0 or higher; HTTP 1.1 support; Ability to perform HTTP redirects; Support TLSv1 / SSLv3 (or higher) with strong security cipher suites; Security options enabled. Given the importance of security awareness, entities with direct relationships with Debtors (namely Banks, Validation Services and Creditors) should promote security awareness, training and education wherever possible. Debtors should be encouraged to adopt security measures advised by the parties such as personal firewalls, antivirus, antispyware and other security mechanisms. 4.3 Creditor requirements This section describes the requirements to be followed by adhering Creditors. It is worthwhile noting that Creditors may choose to either develop a customized implementation of the requirements defined in this specification on their systems or integrate with any possibly available standardized compliant plug-ins. 6 According to the OECD broadband criteria [35], an Internet connection is considered to be broadband if it is capable of download speeds of at least 256 kbit/s. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 38-9 April 2013

39 4.3.1 Setup 1. A contractual agreement with a Creditor Bank must be established in the terms defined in [3] or [4]. 2. A contractual agreement with a Routing Service provider designated by the Creditor Bank must be established in the terms defined in [3] or [4]. This contractual agreement may be either directly with the Routing Service provider or intermediated by the Creditor Bank. 3. The Creditor website must use a TLS X.509 server certificate on the communications with the Debtor to ensure the legitimacy of the website domain name and to enable the usage of HTTPS for data integrity and confidentiality. The choice of the issuing Certification Authority is up to the Creditor but it must choose one that has a certification path recognized by the commonly available web browsers expected to be used by Debtors. 4. HTTPS must be performed using only the strong cipher suites of TLS [22] (a list of strong cipher suites is available in [37]). Weak cipher suites must be disabled on the configuration of the web server. The minimum version of TLS to be supported is 1.0, but Creditors are recommended to migrate to TLS v1.2 as soon as possible (all versions of TLS are retrocompatible for interoperability purposes). 5. The Creditor must choose to either develop a customized implementation of the requirements defined in this specification on their systems or integrate with any possibly available standardized compliant plug-ins. 6. The Creditor must be given by the Routing Service provider the authentication credentials to access the operations available. 7. The Creditor must trust the certification path of the TLS server certificate of the Routing Service provider for HTTPS communications. 8. All stored personal information about Debtors and the e-mandates they hold must be protected in strict accordance with the legal and regulatory requirements and used solely for the purposes explicitly allowed by the respective Debtor Processing The sequence diagram presented below in Figure 11 illustrates the processing steps of the Single Authorization Message Flow for Creditors, while the sequence diagram in Figure 12 illustrates the processing steps of the Multiple Authorizations Message Flow. The only difference in terms of processing is on step 4, which varies according to the information received on step 3. Each of the steps is further detailed on this section. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 39-9 April 2013

40 Figure 11: Sequence diagram of the Single Authorization Message Flow for Creditors Figure 12: Sequence diagram of the Multiple Authorizations Message Flow for Creditors EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 40-9 April 2013

41 1. The Creditor starts the process by collecting all the necessary data about the Debtor in order to build the proposal message. The Creditor may already have some information about the Debtor and pre-fill the corresponding form fields. Both the form presentation and submission at the website must be performed over HTTPS. The form must contain the mandatory national legal wording and the same information about the Creditor that will be present on the e-mandate message. 2. After gathering all the necessary data, the Creditor builds the XML proposal message according to schema eom-msg-cred-to-rs-001 and sends a HTTPS POST to the URL indicated by the Routing Service provider, using the assigned authentication credentials and with the following parameters: Parameter Format Description service Fixed string: mandate Service identifier. operation Fixed string: proposal Operation identifier. eom-message XML message XML proposal message, according to schema eom-msgcred-to-rs-001. If the Creditor does not use a session mechanism (e.g, cookies or URL rewriting), the URL set on element /eom-msg-cred-to-rs-001/payload/eom-data/creditor-return-url 7 must contain sufficient HTTP GET parameters to be able to resume the transaction later at step 5. For security reasons, the URL must also contain a parameter with a randomly generated value: the Random Transaction Token (RTT). The RTT must be an ASCII representation (e.g, hexadecimal, Base64) of a minimum of 16 bytes generated using a cryptographically secure pseudo-random number generator adequately seeded. This is to avoid hijacking and snooping of pending transactions by manipulation of easily guessable parameters on the URL. This POST request contains the service and operation parameters as a repetition of the content of elements /eom-msg-cred-to-rs-001/header/service and /eom-msg-credto-rs-001/header/operation, respectively. This redundancy allows Routing Service providers to filter, reject or dispatch to other chained server processors the incoming requests without having to parse the whole XML message contained in parameter eom-message. The Routing Service provider may define additional data elements to be included on the eom-message or the POST. The Creditor must comply with those additional requirements. After submission of the POST, the Creditor advances the transaction state to Waiting for VS URL (Figure 13). 3. Within a maximum of 10 seconds, the Creditor should receive the response to the POST, containing an XML message according to schema eom-msg-rs-to-cred Depending on the content of element /eom-msg-rs-to-cred-001/payload/status: a. If the value is 0 (zero), depending on the content of element /eom-msg-rs-tocred-001/payload/eom-data: 7 References to values of elements on XML messages are referred using the XPath convention throughout this section. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 41-9 April 2013

42 i. If there is an element vs-url, it means that the Validation Service has chosen the Single Authorization Message Flow and the Creditor must perform a redirect of the Debtor to the Validation Service URL set on that element. The redirect is recommended to be performed by returning an HTTP response code 301 along with the URL. Other methods are permitted but may need further interaction with the Debtor (return an HTML page with a click here to proceed link) or present browser incompatibilities (e.g., usage of JavaScript). By redirecting the Debtor, the Creditor advances the transaction state to Wait for Debtor redirection (Figure 13). ii. Else, if there is an element vs-mandate-ref, it means that the Validation Service has chosen the Multiple Authorizations Message Flow and the Creditor must present the content of that element to the Debtor. It will subsequently be used by the Debtor as a reference to authorize the e- Mandate. iii. Otherwise, an error had occurred and the transaction must be aborted with no further processing. The user shall be presented with an appropriate error message. b. Otherwise, an error had occurred and the transaction must be aborted with no further processing. The user shall be presented with an appropriate error message. 5. Afterwards, the Creditor will only resume the process when the Debtor is sent back by the Validation Service to the URL provided in step 2. This time gap is undetermined, but Creditors shall assume that transactions not completed before the date set on due-date in message eom-msg-cred-to-rs-001 on step 2 are aborted and can be discarded. If possible, the Creditor is recommended to notify the Debtor about the cancellation of the operation. When the Debtor is redirected, a HTTPS GET request is performed to the URL provided in step 2. The Creditor must be able to recover the state and data and resume the transaction with the parameters contained in the GET request. If the transaction is not resumed by means of a session mechanism (e.g., cookies or URL rewriting), the Creditor must also validate that the Random Transaction Token (RTT) included as a parameter in the URL is the same generated on step 2. If it is different, the request must be discarded. 6. The Creditor sends a HTTPS POST to the URL indicated by the Routing Service provider using the assigned authentication credentials and with the following parameters: Parameter Format Description service Fixed string: mandate Service identifier. operation Fixed string: retrieval Operation identifier. eom-message XML message XML retrieval message, according to schema eom-msgcred-to-rs-002. This POST request contains the service and operation parameters as a repetition of the content of elements /eom-msg-cred-to-rs-002/header/service and /eom-msg-credto-rs-002/header/operation, respectively. This redundancy allows Routing Service providers to filter, reject or dispatch to other chained server processors the incoming requests without having to parse the whole XML message contained in parameter eom-message. The Routing Service provider may define additional data elements to be included on the eom-message or the POST; the Creditor must comply with those additional requirements. After submission of the POST, the Creditor advances the transaction state to Waiting for e-mandate (Figure 13). EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 42-9 April 2013

43 7. Within a maximum of 15 seconds, the Creditor should receive the response to the POST, containing an XML message according to schema eom-msg-rs-to-cred-002. Depending on the content of element /eom-msg-rs-to-cred-002/payload/status: a. If the value is 0 (zero), the e-mandate is the content of the XML element /eommsg-rs-to-cred-002/payload/eom-data/signed-message. The e- Mandate contains a XML signature that protects its content. The XML signature is verified by the Routing Service prior to delivery to the Creditor. Nonetheless, Creditors are recommended to verify it also according to the process illustrated in Figure 7. b. Otherwise, an error had occurred and the transaction must be aborted with no further processing. The user shall be presented with an appropriate error message. 8. The Creditor sends a HTTPS POST to the URL indicated by the Routing Service provider using the assigned authentication credentials and with the following parameters: Parameter Format Description service Fixed string: mandate Service identifier. operation Fixed string: acknowledge Operation identifier. eom-message XML message XML acknowledgement message, according to schema eommsg-cred-to-rs-002. This POST request contains the service and operation parameters as a repetition of the content of elements /eom-msg-cred-to-rs-002/header/service and /eom-msg-credto-rs-002/header/operation, respectively. This redundancy allows Routing Service providers to filter, reject or dispatch to other chained server processors the incoming requests without having to parse the whole XML message contained in parameter eom-message. The Routing Service provider may define additional data elements to be included on the eom-message or the POST; the Creditor must comply with those additional requirements. After submitting the POST 9. The Creditor stores the e-mandate and presents a confirmation message along with the e- Mandate data to the Debtor. The transaction is finished. If a recoverable error occurs between steps 6 and 9 (e.g, a connection timeout, lack of disk space on the Creditor, lost e-mandate, etc.), the Creditor has the opportunity to retry the retrieval of the e-mandate. However, once the e-mandate is confirmed to the Debtor, the e-mandate must never be retrieved again by action of the Debtor reusing the URL of step 5 in order to avoid abusive reuses of the URL. Transactions not completed before the date and time set on field due-date of message eom-msgcred-to-rs-001 may be discarded. Creditors are recommended to set due dates long enough such that the several intermediate steps can be processed, but no longer than reasonable for the resources that might be locked during the transaction. In the absence of a specified value for duedate, Creditors must consider a default timeout of 15 minutes for the Single Authorization Message Flow and 48 hours for the Multiple Authorizations Message Flow. Figure 13 illustrates the state transitions for transactions in Creditors according to the processing instructions described above. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 43-9 April 2013

44 Figure 13: State diagram for transactions in Creditors 4.4 Routing Service Provider requirements Setup 1. A contractual agreement with a Creditor Bank must be established in the terms defined in [3] or [4]. 2. The Routing Service provider must apply to the EPC to be able to participate in the e- Operating Model. The application must be sponsored by a Creditor Bank registered at the EPC. 3. The Routing Service web container must use a TLS X.509 server certificate to ensure the legitimacy of the web domain name and to enable the usage of HTTPS for data integrity and confidentiality. The choice of the issuing Certification Authority is up to the Routing Service provider. Incoming Creditors must trust the issuing Certification Authority (or its certification trusted chain) in order to accept the certificate and initiate the communications. 4. An e-operating Model X.509 authentication certificate must be requested from one of the approved EPC Certification Authorities. 5. For the communications of Validation Services and verification of electronic signatures, the Routing Service provider must trust only the EPC approved Certification Authorities and disable all other Certification Authorities. The set of EPC approved Certification Authorities is provided at the adherence of the Routing Service provider and is updated regularly. 6. HTTPS must be performed using only the strong cipher suites defined on TLSv1 [22] (a list of strong cipher suites is available in [37]). Weak cipher suites must be disabled on the configuration of the web server. The minimum version of TLS to be supported is 1.0, but Routing Service providers are recommended to migrate to TLS v1.2 as soon as possible (all versions of TLS are retrocompatible for interoperability purposes). EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 44-9 April 2013

45 7. A contractual agreement with a Directory Service provider must be established in order to have access to the BIC-to-Validation Service resolution data and periodic updates or to an online resolution service. 8. For each applying Creditor, the Routing Service provider must supply: a. Unique authentication credentials; b. The e-operating Model service URL; Processing The sequence diagram presented below in Figure 14 illustrates the processing steps for Routing Services. Each of the steps is further detailed in this section. Figure 14: Sequence diagram for Routing Service providers 1. The Routing Service provider receives an HTTPS POST on the URL indicated to the Creditor. The Routing Service provider must verify the authentication credentials provided by the Creditor to confirm the claimed identity. If the verification fails, the Routing Service provider must return an error message according to schema eom-msg-rs-to-cred-001 and the transaction must be aborted with no further processing. In any case, the verification must be logged to an audit trail. The received POST must contain the following parameters: EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 45-9 April 2013

46 Parameter Format Description service Fixed string: mandate Service identifier. operation Fixed string: proposal Operation identifier. eom-message XML message XML proposal message, according to schema eom-msgcred-to-rs-001. The received POST request contains the service and operation parameters as a repetition of the content of elements /eom-msg-cred-to-rs-001/header/service and /eom-msg-cred-to-rs-001/header/operation, respectively. This redundancy allows the Routing Service provider to filter, reject or dispatch to other chained server processors the incoming requests without having to parse the whole XML message contained in parameter eommessage. The Routing Service provider may define additional convenience data elements that may be included on the eom-message or the POST. Regarding the received parameters, the Routing Service provider must verify that: a. The calling Creditor has permissions to use mandate as a value for service, by checking the terms of the contractual agreement established. b. The value set for parameter operation is proposal. c. The content of parameter eom-message is a valid XML document compliant with schema eom-msg-cred-to-rs-001. d. The content of /eom-msg-cred-to-rs-001/header/service 8 is mandate. e. The content of / eom-msg-cred-to-rs-001/header/operation is proposal. f. The value of /eom-msg-cred-to-rs-001/payload/eom-data/creditorid is a valid Creditor identifier and corresponds to the calling authenticated Creditor. g. The value of element /eom-msg-cred-to-rs-001/payload/eomdata/creditor-return-url is a well-formed URL. h. The content of element /eom-msg-cred-to-rs-001/payload/message is a well-formed XML document. Optionally, the Routing Service provider may verify if it is a valid XML document according to the e-mandate schema. If any of the above conditions fail, the Routing Service provider must return an error message according to schema eom-msg-rs-to-cred-001 and the transaction must be aborted with no further processing. In any case, the verification must be logged to an audit trail. 8 References to values of elements on XML messages are referred using the XPath convention throughout this section. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 46-9 April 2013

47 2. The Routing Service provider gets the Validation Service BIC by parsing the content of element /eom-msg-cred-to-rs-001/payload/eom-data/bic. The parsed BIC is used as the input on a resolution process to obtain the specific EPC e-operating Model entry point URL of the corresponding Validation Service. Directory Service providers maintain updated mappings of BIC/URL for this resolution process. This specification presents two implementation options for this resolution process in Annex C, but Directory Service providers and Routing Service providers may develop others that best suit their needs, as long as the results are equivalently accurate and scalable. If an error occurs on the resolution process, the Routing Service provider must return an error message according to schema eom-msg-rs-to-cred-001 and the transaction must be aborted with no further processing. The result of the resolution process must be logged to an audit trail. 3. The Routing Service provider sends a HTTPS POST to the Validation Service URL using its e-operating Model certificate for mutual authentication and with the following parameters: Parameter Format Description service Fixed string: mandate Service identifier. operation Fixed string: proposal Operation identifier. eom-message XML message XML proposal message, according to schema eom-msg-rsto-vs-001. This POST request contains the service and operation parameters as a repetition of the content of elements /eom-msg-rs-to-vs-001/header/service and /eom-msg-rs-to-vs- 001/header/operation, respectively. This redundancy allows Validation Service providers to filter, reject or dispatch to other chained server processors the incoming requests without having to parse the whole XML message contained in parameter eom-message. At the TLS handshake, the Routing Service provider must verify the certificate presented by the Validation Service according to the process illustrated in Figure 5. According to the certificate verification result: a) If the verification succeeds, the Routing Service provider transmits the request data described above and logs the event to an audit trail. After submission of the POST, the Routing Service provider advances the transaction state to Waiting for VS URL (Figure 15). b) Otherwise, the Routing Service provider must close the connection immediately without transmitting any request data and logs the occurrence to an audit trail. Additionally, the Routing Service provider must return an error message to the Creditor according to schema eom-msg-rs-to-cred-001 and the transaction must be aborted with no further processing. 4. Within a maximum of 10 seconds, the Routing Service provider should receive the response to the POST, which contains a XML message according to schema eom-msgvs-to-rs-001. Depending on the content of element /eom-msg-vs-to-rs- 001/payload/status: a. If the value is 0 (zero), the Validation Service has processed correctly the message sent on step 3. The Routing Service provider logs the event to an audit trail. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 47-9 April 2013

48 b. Otherwise, an error had occurred. The Routing Service provider logs the event to an audit trail and returns a XML error message according to schema eom-msg-rsto-cred-001 to the holding Creditor as the response to the POST received on step 1. The transaction must be aborted with no further processing. 5. The Routing Service provider returns a XML message according to schema eom-msg-rsto-cred-001 to the holding Creditor as the response to the POST received on step 1. After returning the message, the Routing Service provider advances the transaction state to Waiting for e-mandate retrieval. 6. The Routing Service provider receives an HTTPS POST on the URL indicated to the Creditor. The Routing Service provider must verify the authentication credentials provided by the Creditor to confirm the claimed identity. If the verification fails, the Routing Service provider must return an error message according to schema eom-msg-rs-to-cred-002 and the transaction must be aborted with no further processing. In any case, the verification must be logged to an audit trail. The received POST must contain the following parameters: Parameter Format Description service Fixed string: mandate Service identifier. operation Fixed string: retrieval Operation identifier. eom-message XML message XML retrieval message, according to schema eom-msgcred-to-rs-002. The received POST request contains the service and operation parameters as a repetition of the content of elements /eom-msg-cred-to-rs-002/header/service and /eom-msg-cred-to-rs-002/header/operation, respectively. This redundancy allows the Routing Service provider to filter, reject or dispatch to other chained server processors the incoming requests without having to parse the whole XML message contained in parameter eommessage. The Routing Service provider may define additional convenience data elements that may be included on the eom-message or the POST. Regarding the received parameters, the Routing Service provider must verify that: a. The calling Creditor has permissions to use mandate as a value for service, by checking the terms of the contractual agreement established. b. The value set for parameter operation is retrieval. c. The content of parameter eom-message is a valid XML document compliant with schema eom-msg-cred-to-rs-002. d. The content of /eom-msg-cred-to-rs-002/header/service is mandate. e. The content of /eom-msg-cred-to-rs-002/header/operation is retrieval. f. The value of /eom-msg-cred-to-rs-002/payload/eom-data/creditorid is a valid Creditor identifier and corresponds to the calling authenticated Creditor. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 48-9 April 2013

49 g. The value of element /eom-msg-cred-to-rs-002/payload/eomdata/creditor-request_id matches the value of the creditor_request_id element of a transaction in either state Waiting for e- Mandate retrieval or e-mandate acknowledged 9 for the same Creditor and for which an operation proposal has been processed previously. If any of the above conditions fail, the Routing Service provider must return an error message according to schema eom-msg-rs-to-cred-002 and the transaction must be aborted with no further processing. In any case, the verification result must be logged to an audit trail. 7. The Routing Service provider sends a HTTPS POST to the Validation Service URL (the same used on step 3) using its e-operating Model certificate for mutual authentication and with the following parameters: Parameter Format Description service Fixed string: mandate Service identifier. operation Fixed string: retrieval Operation identifier. eom-message XML message XML proposal message, according to schema eom-msg-rsto-vs-002. This POST request contains the service and operation parameters as a repetition of the content of elements /eom-msg-rs-to-vs-002/header/service and /eom-msg-rs-to-vs- 002/header/operation, respectively. This redundancy allows Validation Service providers to filter, reject or dispatch to other chained server processors the incoming requests without having to parse the whole XML message contained in parameter eom-message. At the TLS handshake, the Routing Service provider must verify the certificate presented by the Validation Service according to the process illustrated in Figure 5. According to the certificate verification result: a) If the verification succeeds, the Routing Service provider transmits the request data described above and logs the event to an audit trail. After submission of the POST, the Routing Service provider advances the transaction state to Waiting for e-mandate (Figure 15). b) Otherwise, the Routing Service provider must close the connection immediately without transmitting any request data and logs the occurrence to an audit trail. Additionally, the Routing Service provider must return an error message to the Creditor according to schema eom-msg-rs-to-cred-002 and the transaction must be aborted with no further processing. 8. Within a maximum of 15 seconds, the Routing Service provider should receive the response to the POST, containing an XML message according to schema eom-msg-vsto-rs-002. Depending on the content of element /eom-msg-vs-to-rs- 002/payload/status: a. If it is 0 (zero), the Validation Service has processed correctly the message sent on step 7. The Routing Service provider logs the event to an audit trail. 9 This allows retrials of the operation retrieval by Creditors. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 49-9 April 2013

50 b. Otherwise, an error had occurred. The Routing Service provider logs the event to an audit trail and returns a XML error message according to schema eom-msg-rsto-cred-002 to the holding Creditor as the response to the POST received on step 6. The transaction must be aborted with no further processing. 9. The received XML message contains the e-mandate as the content of element /eom-msgvs-to-rs-002/payload/message. The e-mandate is protected with an enveloping XML Signature. At this step, the Routing Service provider must verify the electronic signature according to the process illustrated in Figure Depending on the result of the signature verification: a. If it succeeds, the Routing Service provider logs the event to an audit trail and returns a XML message according to schema eom-msg-rs-to-cred-002 to the holding Creditor as the response to the POST received on step 7. The XML enveloping signature received on step 8 must be embedded into element /eommsg-rs-to-cred-002/payload/eom-data/signed-message. The Routing Service provider sets the state of the transaction to e-mandate retrieved. b. Otherwise, the signature is invalid. The Routing Service provider logs the event to an audit trail and returns a XML error message according to schema eom-msg-rsto-cred-002 to the holding Creditor as the response to the POST received on step 7. The transaction must be aborted with no further processing. 11. The Routing Service provider receives an HTTPS POST on the URL indicated to the Creditor. The Routing Service provider must verify the authentication credentials provided by the Creditor to confirm the claimed identity. If the verification fails, the Routing Service provider must return an error message according to schema eom-msg-rs-to-cred-002 and the transaction must be aborted with no further processing. In any case, the verification must be logged to an audit trail. The received POST must contain the following parameters: Parameter Format Description service Fixed string: mandate Service identifier. operation Fixed string: acknowledge Operation identifier. eom-message XML message XML acknowledgement message, according to schema eommsg-cred-to-rs-002. The received POST request contains the service and operation parameters as a repetition of the content of elements /eom-msg-cred-to-rs-002/header/service and /eom-msg-cred-to-rs-002/header/operation, respectively. This redundancy allows the Routing Service provider to filter, reject or dispatch to other chained server processors the incoming requests without having to parse the whole XML message contained in parameter eommessage. The Routing Service provider may define additional convenience data elements that may be included on the eom-message or the POST. Regarding the received parameters, the Routing Service provider must verify that: a. The calling Creditor has permissions to use mandate as a value for service, by checking the terms of the contractual agreement established. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 50-9 April 2013

51 b. The value set for parameter operation is acknowledge. c. The content of parameter eom-message is a valid XML document compliant with schema eom-msg-cred-to-rs-002. d. The content of /eom-msg-cred-to-rs-002/header/service is mandate. e. The content of /eom-msg-cred-to-rs-002/header/operation is acknowledge. f. The value of /eom-msg-cred-to-rs-002/payload/eom-data/creditorid is a valid Creditor identifier and corresponds to the calling authenticated Creditor. g. The value of element /eom-msg-cred-to-rs-002/payload/eomdata/creditor-request_id matches the value of the creditor_request_id element of a transaction in state Waiting for acknowledge for the same Creditor and for which an operation retrieval has been processed previously. If any of the above conditions fail, the Routing Service must abort the transaction with no further processing. In any case, the verification must be logged to an audit trail. 12. The Routing Service provider sends a HTTPS POST to the Validation Service URL (the same used on step 3) using its e-operating Model certificate for mutual authentication and with the following parameters: Parameter Format Description service Fixed string: mandate Service identifier. operation Fixed string: acknowledge Operation identifier. eom-message XML message XML acknowledgement message, according to schema eommsg-rs-to-vs-002. This POST request contains the service and operation parameters as a repetition of the content of elements /eom-msg-rs-to-vs-002/header/service and /eom-msg-rs-to-vs- 002/header/operation, respectively. This redundancy allows Validation Service providers to filter, reject or dispatch to other chained server processors the incoming requests without having to parse the whole XML message contained in parameter eom-message. At the TLS handshake, the Routing Service provider must verify the certificate presented by the Validation Service according to the process illustrated in Figure 5. According to the certificate verification result: a) If the verification succeeds, the Routing Service provider transmits the request data described above and logs the event to an audit trail. After submission of the POST, the Routing Service provider sets the state of the transaction to e-mandate acknowledged (Figure 15). b) Otherwise, the Routing Service provider must close the connection immediately without transmitting any request data and logs the occurrence to an audit trail. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 51-9 April 2013

52 Transactions not completed before the date and time set on field due-date of message eom-msgcred-to-rs-001 may be discarded. In the absence of a specified value for due-date, Routing Service providers must consider a default timeout of 48 hours 10. Figure 15 illustrates the state transitions for transactions in Routing Service providers according to the processing instructions described above. Figure 15: State diagram for transactions in Routing Service providers 4.5 Validation Service Provider requirements Setup 1. A contractual agreement with the Debtor Bank must be established in the terms defined in [3] iand [4]. 2. The Validation Service provider must apply to the EPC to be able to participate in the e- Operating Model. The application must be sponsored by the Debtor Bank registered at the EPC. Thus, the application to the EPC must be performed on a per-bic basis. 3. An e-operating Model X.509 authentication certificate must be requested from one of the approved EPC Certification Authorities. 10 Since Routing Service providers are not required to process differently the two message flows defined (Single Authorization and Multiple Authorizations), the 48 hours default timeout is to accommodate both of them. However, Routing Service providers that are able to distinguish the message flows (see description of step 4.a in section 4.3.2) may set the default timeout for the Single Authorization Message Flow to 15 minutes. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 52-9 April 2013

53 4. For each registered BIC, an e-operating Model X.509 signing certificate must be requested from one of the approved EPC Certification Authorities. 5. The keys for the signing certificates described in requirement 4 must be generated and kept secure in a Signature Creation Device adequate for performing Advanced Electronic Signatures. These devices are typically Hardware Security Modules with certification FIPS 140-1/2 Level 2 or higher, or Common Criteria EAL 3 or higher. 6. For the communications of Routing Services, the Validation Service provider must trust only the EPC approved Certification Authorities and disable all other Certification Authorities. The set of EPC approved Certification Authorities is provided at the adherence of the Validation Service provider and is updated regularly. 7. HTTPS must be performed using only the strong cipher suites defined on TLSv1 [22] (a list of strong cipher suites is available in [37]). Weak cipher suites must be disabled on the configuration of the web server. The minimum version of TLS to be supported is 1.0, but Validation Service providers are recommended to migrate to TLS v1.2 as soon as possible (all versions of TLS are retrocompatible for interoperability purposes). 8. The Validation Service provider must communicate to the EPC the URL to which it will be willing to process e-operating Model messages for a given BIC. All updates to the URL must be communicated to the EPC Processing The sequence diagram presented below in Figure 16 illustrates the processing steps of the Single Authorization Message Flow (SAMF) for Validation Services, while the sequence diagram in Figure 17 illustrates the processing steps of the Multiple Authorizations Message Flow (MAMF). Validation Services that want to avoid automatic redirects from Creditors or need multiple authorizations should adopt the MAMF. Each of the steps for the SAMF are further detailed in section and for MAMF in section EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 53-9 April 2013

54 Figure 16: Sequence diagram of the Single Authorization Message Flow for Validation Service providers EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 54-9 April 2013

55 Figure 17: Sequence diagram of the Multiple Authorizations Message Flow for Validation Service providers Single Authorization Message Flow 1. The Validation Service provider receives an HTTPS POST on the URL registered at the EPC for the requested BIC. At the TLS handshake, the Validation Service provider must verify the certificate presented by the Routing Service according to the process illustrated in Figure 5. Depending on the certificate verification result: a. If the verification succeeds, the Validation Service proceeds with the request and logs the event to an audit trail. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 55-9 April 2013

56 b. Otherwise, the Validation Service provider must close the connection immediately without receiving any further request data and logs the occurrence to an audit trail. Additionally, the Validation Service provider must return an error message to the Routing Service according to schema eom-msg-vs-to-rs-001 and the transaction must be aborted with no further processing. If the Validation Service provider is not able to return an error message conforming to eom-msg-vs-tors-001, it must return an HTTP status code 403 (Forbidden). The received POST must contain the following parameters: Parameter Format Description service Fixed string: mandate Service identifier. operation Fixed string: proposal Operation identifier. eom-message XML message XML proposal message, according to schema eom-msg-rsto-vs-001. The received POST request contains the service and operation parameters as a repetition of the content of elements /eom-msg-rs-to-vs-001/header/service and /eommsg-rs-to-vs-001/header/operation, respectively. This redundancy allows Validation Service providers to filter, reject or dispatch to other chained server processors the incoming requests without having to parse the whole XML message contained in parameter eom-message. 2. Regarding the received parameters, the Validation Service provider must verify that: a. The value set for parameter service is mandate. b. The value set for parameter operation is proposal. c. The content of parameter eom-message is a valid XML document compliant with schema eom-msg-rs-to-vs-001. d. The content of /eom-msg-rs-to-vs-001/header/service 11 is mandate. e. The content of / eom-msg-rs-to-vs-001/header/operation is proposal. f. The value of element /eom-msg-rs-to-vs-001/payload/eomdata/creditor-return-url is a well-formed URL. g. The content of element /eom-msg-rs-to-vs-001/payload/message is a valid XML document compliant with the e-mandate schema. If any of the above conditions fail, the Validation Service provider must return an error message according to schema eom-msg-vs-to-rs-001 and the transaction must be aborted with no further processing. Otherwise, the Validation Service provider stores the received data. In any case, the results of the verifications must be logged to an audit trail. 11 References to values of elements on XML messages are referred using the XPath convention throughout this section. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 56-9 April 2013

57 3. In response to the received POST, the Validation Service provider returns a XML message according to schema eom-msg-vs-to-rs-001 for SAMF (i.e. providing a URL at the Validation Service on the content of elementc /eom-msg-vs-to-rs- 001/payload/eom-data/vs-url for which the Debtor will subsequentely be redirected by the Creditor in step 4), and advances the transaction state to Waiting for Debtor redirection (Figure 18). 4. The Debtor is redirected by the Creditor to the Validation Service URL provided at element /eom-msg-vs-to-rs-001/payload/eom-data/vs-url on the message returned in step The Validation Service provider retrieves the data about the request previously stored on step 2 and presents an authentication screen to the Debtor. The transaction state advances to Waiting for authentication means (Figure 18). 6. The Debtor enters the authentication credentials agreed with the Debtor Bank The authentication credentials may be composed of personalised device(s) and/or a set of procedures, including its personalized security features. 7. The Validation Service verifies the correctness of the authentication credentials provided and logs the event to an audit trail. 8. Depending on the results of the verification of the authentication credentials: a. If the authentication credentials provided are correct and valid, the Validation Service presents an authorization form that must include all data fields of the e- mandate and advances the transaction state to Waiting for authorization (Figure 18). b. If the authentication can not be correctly verified (even after a limited number of retrials of steps 6 and 7), an error message must be presented and the transaction must be aborted with no further processing. 9. The Debtor is asked to verify all the data fields of the e-mandate (e.g., the accuracy of the Creditor s name and address, the Debtor s account identifier, etc.) along with the mandatory national legal wording and then proceeds with the authorization. The authorization is defined [3], [4] as the set of procedures agreed between the Debtor and the Debtor Bank to assure the clear consent of the Debtor for the issuing, amendment or cancellation of an e-mandate. If the IBAN was not set on the e-mandates message received in step 1, the Debtor must choose one of the accounts for which he is the holder and has direct debits rights. 10. The Validation Service verifies the authorization and performs an electronic signature of the XML e-mandate data using the e-operating Model X.509 signing certificate issued by an approved EPC Certification Authority. The electronic signature must be generated by a Signature Creation Application (SCA) compliant with CWA [27], using a Signature Creation Device adequate for performing Advanced Electronic Signatures. These devices are typically Hardware Security Modules with certification FIPS 140-1/2 Level 2 or higher, or Common Criteria EAL 3 or higher. The format of the electronic signature must be an enveloping XML signature in accordance with XML Advanced Electronic Signatures (XAdES) [31], in the form of Basic Electronic Signatures (XAdES-BES) conforming to the profile defined in Table 5. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 57-9 April 2013

58 Element CanonicalizationMethod SignatureMethod Reference DigestMethod Reference DigestMethod KeyInfo Object Table 5: XAdES-BES profile for the EPC e-operating Model = = = = = = = keyinfo Must include a X509Data element containing X509Certificate elements for the signing certificate and the certificates composing the trusted certification chain. The first X509Certificate must be the signing certificate and last must be the root Certification = message The XAdES-BES signature will have the following sample structure: <Signature xmlns=" <SignedInfo> <CanonicalizationMethod Algorithm=" <SignatureMethod Algorithm=" <Reference URI="#message"> <DigestMethod Algorithm=" <DigestValue>...</DigestValue> </Reference> <Reference URI="#keyInfo"> <DigestMethod Algorithm=" <DigestValue>...</DigestValue> </Reference> </SignedInfo> <SignatureValue>...</SignatureValue> <KeyInfo Id="keyInfo"> <X509Data> <X509Certificate>...</X509Certificate> <!-- Signing certificate --> <X509Certificate>...</X509Certificate> <!-- Root CA certificate --> </X509Data> </KeyInfo> <Object Id="message">...</Object> </Signature> A complete XML sample message of eom-msg-vs-to-rs-002 can be found in annex B The Validation Service presents a confirmation message to the Debtor along with the e- Mandate data and a link to the Creditor website (URL provided at element /eom-msg-rsto-vs-001/payload/eom-data/creditor-return-url on the message received in step 1). The transaction state advances to Waiting for e-mandate retrieval (Figure 18). 12. The Validation Service provider receives an HTTPS POST from the same Routing Service provider, on the same URL as the message received in step 1. At the TLS handshake, the Validation Service provider must verify the certificate presented by the Routing Service according to the process illustrated in Figure 5. Depending on the certificate verification result: EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 58-9 April 2013

59 a. If the verification succeeds, the Validation Service proceeds with the request and logs the event to an audit trail. b. Otherwise, the Validation Service provider must close the connection immediately without receiving any further request data and logs the occurrence to an audit trail. Additionally, the Validation Service provider must return an error message to the Routing Service according to schema eom-msg-vs-to-rs-002 and the transaction must be aborted with no further processing. If the Validation Service provider is not able to return an error message conforming to eom-msg-vs-tors-002, it must return an HTTP status code 403 (Forbidden). The received POST must contain the following parameters: Parameter Format Description service Fixed string: mandate Service identifier. operation Fixed string: retrieval Operation identifier. eom-message XML message XML proposal message, according to schema eom-msg-rsto-vs-002. The received POST request contains the service and operation parameters as a repetition of the content of elements /eom-msg-rs-to-vs-002/header/service and /eommsg-rs-to-vs-002/header/operation, respectively. This redundancy allows Validation Service providers to filter, reject or dispatch to other chained server processors the incoming requests without having to parse the whole XML message contained in parameter eom-message. Regarding the received parameters, the Validation Service provider must verify that: a. The value set for parameter service is mandate. b. The value set for parameter operation is retrieval. c. The content of parameter eom-message is a valid XML document compliant with schema eom-msg-rs-to-vs-002. d. The content of /eom-msg-rs-to-vs-002/header/service is mandate. e. The content of /eom-msg-rs-to-vs-002/header/operation is retrieval. f. The value of elements /eom-msg-rs-to-vs-002/payload/eomdata/creditor-id and /eom-msg-rs-to-vs-002/payload/eomdata/creditor-request-id matches the value of the combined key creditor-id and creditor-request-id element of a transaction in either state Waiting for e-mandate retrieval or e-mandate retrieved 12 for the same Routing Service provider and for which a proposal operation has been processed previously. If any of the above conditions fail, the Validation Service provider must return an error message according to schema eom-msg-vs-to-rs-002 and the transaction must be aborted with no further processing. In any case, the verification must be logged to an audit trail. 12 This allows retrials of the operation retrieval by Creditors.. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 59-9 April 2013

60 13. In response to the POST, the Validation Service provider returns a XML message according to schema eom-msg-rs-to-vs-002, embedding the XML enveloping signature performed on step 10 into element /eom-msg-rs-to-vs-002/payload/eomdata/signed-message. The transaction state is set to e-mandate retrieved (Figure 18) 14. The Validation Service provider receives an HTTPS POST from the same Routing Service provider, on the same URL as the message received in step 1. At the TLS handshake, the Validation Service provider must verify the certificate presented by the Routing Service according to the process illustrated in Figure 5. Depending on the certificate verification result: a. If the verification succeeds, the Validation Service proceeds with the request and logs the event to an audit trail. b. Otherwise, the Validation Service provider must close the connection immediately without receiving any further request data and logs the occurrence to an audit trail. The transaction must be aborted with no further processing. The received POST must contain the following parameters: Parameter Format Description service Fixed string: mandate Service identifier. operation Fixed string: acknowledge Operation identifier. eom-message XML message XML acknowledgement message, according to schema eommsg-rs-to-vs-002. The received POST request contains the service and operation parameters as a repetition of the content of elements /eom-msg-rs-to-vs-002/header/service and /eommsg-rs-to-vs-002/header/operation, respectively. This redundancy allows Validation Service providers to filter, reject or dispatch to other chained server processors the incoming requests without having to parse the whole XML message contained in parameter eom-message. Regarding the received parameters, the Validation Service provider must verify that: a. The value set for parameter service is mandate. b. The value set for parameter operation is acknowledge. c. The content of parameter eom-message is a valid XML document compliant with schema eom-msg-rs-to-vs-002. d. The content of /eom-msg-rs-to-vs-002/header/service is mandate. e. The content of /eom-msg-rs-to-vs-002/header/operation is acknowledge. f. The value of elements /eom-msg-rs-to-vs-002/payload/eomdata/creditor-id and /eom-msg-rs-to-vs-002/payload/eomdata/creditor-request-id matches the value of the combined key creditor-id and creditor-request-id element of a transaction in state Waiting for e-mandate retrieval for the same Routing Service provider and for which a proposal operation has been processed previously. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 60-9 April 2013

61 If any of the above conditions fail, the Validation Service provider must discard the message with no further processing. Otherwise, the Validation Service advances the transaction state to e-mandate acknowledged (Figure 18). In any case, the verification must be logged to an audit trail. Transactions not completed before the date and time set on field due-date of message eom-msgrs-to-vs-001 may be discarded. In the absence of a specified value for due-date, Validation Service providers must consider a default timeout of 15 minutes for the Single Authorization Message Flow and 48 hours for the Multiple Authorizations Message Flow. Figure 18 illustrates the state transitions for transactions in Validation Service providers according to the processing instructions described above. Figure 18: State diagram of the Single Authorization Message Flow for transactions in Validation Service providers Multiple Authorizations Message Flow 1. The Validation Service provider receives an HTTPS POST on the URL registered at the EPC for the requested BIC. At the TLS handshake, the Validation Service provider must verify the certificate presented by the Routing Service according to the process illustrated in Figure 5. Depending on the certificate verification result: a. If the verification succeeds, the Validation Service proceeds with the request and logs the event to an audit trail. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 61-9 April 2013

62 b. Otherwise, the Validation Service provider must close the connection immediately without receiving any further request data and logs the occurrence to an audit trail. Additionally, the Validation Service provider must return an error message to the Routing Service according to schema eom-msg-vs-to-rs-001 and the transaction must be aborted with no further processing. If the Validation Service provider is not able to return an error message conforming to eom-msg-vs-tors-001, it must return an HTTP status code 403 (Forbidden). The received POST must contain the following parameters: Parameter Format Description service Fixed string: mandate Service identifier. operation Fixed string: proposal Operation identifier. eom-message XML message XML proposal message, according to schema eom-msg-rsto-vs-001. The received POST request contains the service and operation parameters as a repetition of the content of elements /eom-msg-rs-to-vs-001/header/service and /eommsg-rs-to-vs-001/header/operation, respectively. This redundancy allows Validation Service providers to filter, reject or dispatch to other chained server processors the incoming requests without having to parse the whole XML message contained in parameter eom-message. 2. Regarding the received parameters, the Validation Service provider must verify that: a. The value set for parameter service is mandate. b. The value set for parameter operation is proposal. c. The content of parameter eom-message is a valid XML document compliant with schema eom-msg-rs-to-vs-001. d. The content of /eom-msg-rs-to-vs-001/header/service 13 is mandate. e. The content of / eom-msg-rs-to-vs-001/header/operation is proposal. f. The value of element /eom-msg-rs-to-vs-001/payload/eomdata/creditor-return-url is a well-formed URL. g. The content of element /eom-msg-rs-to-vs-001/payload/message is a valid XML document compliant with the e-mandate schema. If any of the above conditions fail, the Validation Service provider must return an error message according to schema eom-msg-vs-to-rs-001 and the transaction must be aborted with no further processing. Otherwise, the Validation Service provider stores the received data. In any case, the results of the verifications must be logged to an audit trail. 13 References to values of elements on XML messages are referred using the XPath convention throughout this section. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 62-9 April 2013

63 3. In response to the received POST, the Validation Service provider returns a XML message according to schema eom-msg-vs-to-rs-001 for MAMF (i.e. assigning a unique proposal reference on the element /eom-msg-vs-to-rs-001/payload/eom-data/vsmandate-ref that the Debtor can subsequentely use on step 9), and advances the transaction state to Waiting for Debtor (Figure 19). 4. The Debtor enters into the Validation Service authentication homepage. 5. The Validation Service provider presents an authentication screen to the Debtor. The transaction state advances to Waiting for authentication means (Figure 19). 6. The Debtor enters the authentication credentials agreed with the Debtor Bank The authentication credentials may be composed of personalised device(s) and/or a set of procedures, including its personalized security features. 7. The Validation Service verifies the correctness of the authentication credentials provided and logs the event to an audit trail. 8. Depending on the results of the verification of the authentication credentials: a. If the authentication credentials provided are correct and valid, the Validation Service presents a form to the Debtor to enter the identifier code set on step 3 or a list of pending e-mandate requests. b. If the authentication can not be correctly verified (even after a limited number of retrials of steps 6 and 7), an error message must be presented and the transaction must be aborted with no further processing. 9. The Debtor enters the proposal reference of the pending e-mandate request to be authorized (or selects it from the list). If the IBAN is not already selected for the e-mandate (it might have been set on the e-mandates message received in step 1 or another account holder has already chosen on a previous authorization), the Debtor must choose one of the accounts for which he is one of the holders and has direct debits rights. 10. According to the data received, a. if it is valid, the Debtor is asked to verify all the data fields of the e-mandate (e.g., the accuracy of the Creditor s name and address, the Debtor s account identifier, etc.) along with the mandatory national legal wording and then proceeds with the authorization. The authorization is defined [3], [4] as the set of procedures agreed between the Debtor and the Debtor Bank to assure the clear consent of the Debtor for the issuing, amendment or cancellation of an e-mandate. b. otherwise, the Debtor might be given another opportunity to enter the correct data by returning to step 8.a. 11. The Validation Service receives the authorization and proceeds as the following: a. If multiple authorizations are required for that account (a typical B2B scenario), the Validation Service must gather enough authorizations from the other account holders, by repeating steps 4 through 11. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 63-9 April 2013

64 Element CanonicalizationMethod SignatureMethod Reference DigestMethod Reference DigestMethod b. If all required authorizations were already gathered, the Validation Service performs an electronic signature of the XML e-mandate data using the e-operating Model X.509 signing certificate issued by an approved EPC Certification Authority. The electronic signature must be generated by a Signature Creation Application (SCA) compliant with CWA [27], using a Signature Creation Device adequate for performing Advanced Electronic Signatures. These devices are typically Hardware Security Modules with certification FIPS 140-1/2 Level 2 or higher, or Common Criteria EAL 3 or higher. The format of the electronic signature must be an enveloping XML signature in accordance with XML Advanced Electronic Signatures (XAdES) [31], in the form of Basic Electronic Signatures (XAdES-BES) conforming to the profile defined in Table 5. Table 6: XAdES-BES profile for the EPC e-operating Model = = = = = = KeyInfo = keyinfo Must include a X509Data element containing X509Certificate elements for the signing certificate and the certificates composing the trusted certification chain. The first X509Certificate must be the signing certificate and last must be the root Certification = message The XAdES-BES signature will have the following sample structure: <Signature xmlns=" <SignedInfo> <CanonicalizationMethod Algorithm=" <SignatureMethod Algorithm=" <Reference URI="#message"> <DigestMethod Algorithm=" <DigestValue>...</DigestValue> </Reference> <Reference URI="#keyInfo"> <DigestMethod Algorithm=" <DigestValue>...</DigestValue> </Reference> </SignedInfo> <SignatureValue>...</SignatureValue> <KeyInfo Id="keyInfo"> <X509Data> <X509Certificate>...</X509Certificate> <!-- Signing certificate --> <X509Certificate>...</X509Certificate> <!-- Root CA certificate --> </X509Data> </KeyInfo> <Object Id="message">...</Object> </Signature> B.9. A complete XML sample message of eom-msg-vs-to-rs-002 can be found in annex EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 64-9 April 2013

65 12. The Validation Service presents a confirmation message to the Debtor along with the e- Mandate data and a link to the Creditor website (URL provided at element /eom-msg-rsto-vs-001/payload/eom-data/creditor-return-url on the message received in step 1). The transaction state advances to Waiting for e-mandate retrieval (Figure 19). 13. The Validation Service provider receives an HTTPS POST from the same Routing Service provider, on the same URL as the message received in step 1. At the TLS handshake, the Validation Service provider must verify the certificate presented by the Routing Service according to the process illustrated in Figure 5. Depending on the certificate verification result: a. If the verification succeeds, the Validation Service proceeds with the request and logs the event to an audit trail. b. Otherwise, the Validation Service provider must close the connection immediately without receiving any further request data and logs the occurrence to an audit trail. Additionally, the Validation Service provider must return an error message to the Routing Service according to schema eom-msg-vs-to-rs-002 and the transaction must be aborted with no further processing. If the Validation Service provider is not able to return an error message conforming to eom-msg-vs-tors-002, it must return an HTTP status code 403 (Forbidden). The received POST must contain the following parameters: Parameter Format Description service Fixed string: mandate Service identifier. operation Fixed string: retrieval Operation identifier. eom-message XML message XML proposal message, according to schema eom-msg-rsto-vs-002. The received POST request contains the service and operation parameters as a repetition of the content of elements /eom-msg-rs-to-vs-002/header/service and /eommsg-rs-to-vs-002/header/operation, respectively. This redundancy allows Validation Service providers to filter, reject or dispatch to other chained server processors the incoming requests without having to parse the whole XML message contained in parameter eom-message. Regarding the received parameters, the Validation Service provider must verify that: a. The value set for parameter service is mandate. b. The value set for parameter operation is retrieval. c. The content of parameter eom-message is a valid XML document compliant with schema eom-msg-rs-to-vs-002. d. The content of /eom-msg-rs-to-vs-002/header/service is mandate. e. The content of /eom-msg-rs-to-vs-002/header/operation is retrieval. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 65-9 April 2013

66 f. The value of elements /eom-msg-rs-to-vs-002/payload/eomdata/creditor-id and /eom-msg-rs-to-vs-002/payload/eomdata/creditor-request-id matches the value of the combined key creditor-id and creditor-request-id element of a transaction in either state Waiting for e-mandate retrieval or e-mandate retrieved 14 for the same Routing Service provider and for which a proposal operation has been processed previously. If any of the above conditions fail, the Validation Service provider must return an error message according to schema eom-msg-vs-to-rs-002 and the transaction must be aborted with no further processing. In any case, the verification must be logged to an audit trail. 14. In response to the POST, the Validation Service provider returns a XML message according to schema eom-msg-rs-to-vs-002, embedding the XML enveloping signature performed on step 10 into element /eom-msg-rs-to-vs-002/payload/eomdata/signed-message. The transaction state is set to e-mandate retrieved (Figure 19) 15. The Validation Service provider receives an HTTPS POST from the same Routing Service provider, on the same URL as the message received in step 1. At the TLS handshake, the Validation Service provider must verify the certificate presented by the Routing Service according to the process illustrated in Figure 5. Depending on the certificate verification result: a. If the verification succeeds, the Validation Service proceeds with the request and logs the event to an audit trail. b. Otherwise, the Validation Service provider must close the connection immediately without receiving any further request data and logs the occurrence to an audit trail. The transaction must be aborted with no further processing. The received POST must contain the following parameters: Parameter Format Description service Fixed string: mandate Service identifier. operation Fixed string: acknowledge Operation identifier. eom-message XML message XML acknowledgement message, according to schema eommsg-rs-to-vs-002. The received POST request contains the service and operation parameters as a repetition of the content of elements /eom-msg-rs-to-vs-002/header/service and /eommsg-rs-to-vs-002/header/operation, respectively. This redundancy allows Validation Service providers to filter, reject or dispatch to other chained server processors the incoming requests without having to parse the whole XML message contained in parameter eom-message. Regarding the received parameters, the Validation Service provider must verify that: a. The value set for parameter service is mandate. b. The value set for parameter operation is acknowledge. 14 This allows retrials of the operation retrieval by Creditors. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 66-9 April 2013

67 c. The content of parameter eom-message is a valid XML document compliant with schema eom-msg-rs-to-vs-002. d. The content of /eom-msg-rs-to-vs-002/header/service is mandate. e. The content of /eom-msg-rs-to-vs-002/header/operation is acknowledge. f. The value of elements /eom-msg-rs-to-vs-002/payload/eomdata/creditor-id and /eom-msg-rs-to-vs-002/payload/eomdata/creditor-request-id matches the value of the combined key creditor-id and creditor-request-id element of a transaction in state Waiting for e-mandate retrieval for the same Routing Service provider and for which a proposal operation has been processed previously. If any of the above conditions fail, the Validation Service provider must discard the message with no further processing. Otherwise, the Validation Service advances the transaction state to e-mandate acknowledged (Figure 19). In any case, the verification must be logged to an audit trail. Transactions not completed before the date and time set on field due-date of message eom-msgrs-to-vs-001 may be discarded. In the absence of a specified value for due-date, Validation Service providers must consider a default timeout of 15 minutes for the Single Authorization Message Flow and 48 hours for the Multiple Authorizations Message Flow. Figure 19 illustrates the state transitions for transactions in Validation Service providers according to the processing instructions described above. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 67-9 April 2013

68 Figure 19: State diagram of the Multiple Authorizations Message Flow for transactions in Validation Service providers 4.6 Directory Service requirements In order to be an EPC e-operating Model Directory Service provider, an applicant must comply with the following requirements: 1. A contractual agreement with the EPC must be established in order to be recognized as a legitimate EPC e-operating Model Directory Service provider. 2. The Directory Service provider must establish a protocol to securely receive information about: a. Current adherent BICs and respective URLs of its designated Validation Services; b. New adherent BICs and respective URLs of their designated Validation Services; c. Changes to URLs of registered BICs; d. Cessation of operation of BICs. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 68-9 April 2013

69 3. The Directory Service provider must offer to customer Routing Service providers at least one BIC resolution method, i.e., a method to obtain the Validation Service URL associated to a given BIC. This specification recommends two methods in Annex C. Nonetheless, a Directory Service provider may develop other equivalent methods as long as they ensure equivalent levels of availability, performance and throughput. 4. If the Directory Service provider distributes mapping data or results online, it must use a TLS X.509 server certificate on the web container to ensure the legitimacy of the web domain name and to enable the usage of HTTPS for data integrity and confidentiality. The choice of the issuing Certification Authority is up to the Directory Service provider. Incoming Routing Service providers must trust the issuing Certification Authority (or its certification trusted chain) in order to accept the certificate and initiate the communications. 5. If the Directory Service uses other out-of-band methods (e.g., a CD) to disseminate the mapping data, it must use a secure protocol that guarantees the authentication of the parties and the integrity of the distributed data. 4.7 Certification Authority requirements In order to be accepted and listed on the EPC portal as an EPC approved Certification Authority (CA), an applicant CA must comply with the following requirements: 1. Successfully pass the Approval Scheme for EPC Approved CAs [7]. 2. Be able to issue certificates in accordance with the customized certificate profiles defined in Annex E. 3. Strictly follow the enrolment steps defined in Annex D for applying Routing Service and Validation Service providers. 4. Offer an accessible Certificate Revocation List (CRL) for certificate status validation and an Online Certificate Status Protocol (OCSP) service. 5. Strictly follow CWA (for Non-Qualified Certificates) [28] and TS (for Normalized Certificate Policy) [30]. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 69-9 April 2013

70 5 MESSAGE SPECIFICATION This chapter presents a comprehensive description of the EPC e-operating Model XML messages. The following eight messages are defined: 1. eom-msg-cred-to-rs-001 message sent by the Creditor to the Routing Service to initiate the e-mandate request. 2. eom-msg-rs-to-vs-001 message sent by the Routing Service to the Validation Service to route the e-mandate request data. 3. eom-msg-vs-to-rs-001 return message sent by the Validation Service to the Routing Service. 4. eom-msg-rs-to-cred-001 return message sent by the Routing Service to the Creditor. 5. eom-msg-cred-to-rs-002 message sent by the Creditor to the Routing Service to retrieve the e-mandate. 6. eom-msg-rs-to-vs-002 message sent by the Routing Service to the Validation Service to retrieve the e-mandate. 7. eom-msg-vs-to-rs-002 return message sent by the Validation Service to the Routing Service containing the e-mandate. 8. eom-msg-rs-to-cred-002 return message sent by the Routing Service to the Creditor containing the e-mandate. 5.1 Notation Conventions The multiplicity (or the range of occurrences) of each element, is defined by the Mult column in the format [a..b], where: a, is the minimum number of occurrences and b, is the maximum number of occurrences. Value n means an unlimited number of occurrences Conditional relationships between components of a message element (for example, either component 1 or component 2 must be present, but not both) are indicated in the Mult column as {Or and Or}. When an element contains sub-elements these are noted with a plus sign ( + ) per level in the Element column. An element name followed by the and a label, means that the label is an attribute of that element. 5.2 EPC e-operating Model Messages eom-msg-cred-to-rs-001 The message type eom-msg-cred-to-rs-001 is generated and sent by Creditors to Routing Services in order to initiate e-mandate proposal requests. The data elements that compose this message type are detailed in Table 7 and the corresponding XML schema is presented in annex A.3. Table 7: Description of message eom-msg-cred-to-rs-001 EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 70-9 April 2013

71 Mult Element Format/Type Description [1..1] eom-msg-cred-to-rs-001 [1..1] + header [1..1] + header@version string [1..1] ++ date datetime [1..1] ++ service Service [1..1] ++ operation Operation Version of message format. Usage Rule: Must have the value 1.1. Message timestamp. Usage Rule: Current date and time of generation of the message. Must be in UTC (suffix Z) or include timezone information, as defined in RFC 3339 [20]. Service identification tip. Usage Rule: Must have the value mandate. Operation identification tip. Usage Rule: Must have the value proposal. [1..1] + payload [1..1] ++ eom-data [1..1] +++ vs-address string [1..1] +++ vs-address@type string [1..1] +++ creditor-id ReferenceID [1..1] +++ creditor-request-id ReferenceID [1..1] +++ creditor-return-url URL [0..1] +++ due-date datetime Addressing information of the Validation Service. Usage Rule: Must have the Bank Identifier Code (BIC) of the Debtor Bank. Type of addressing information of the Validation Service. Usage Rule: Must have the value BIC. Identifier of the Creditor requesting the e-mandate. Usage Rule: Must be set in accordance with the rules defined for field AT-02 (Identifier of the Creditor) in [2] Creditor s request identifier. Usage Rule: This identifier must be unique per request. Creditor s website URL for later redirection of the Debtor s browser back to the Creditor. Usage Rule: Must contain sufficient HTTP GET parameters to be able to resume the transaction at a later step. Maximum allowed date set by the Creditor for the whole transaction to be completed before it is discarded. Usage Rule: Must be in UTC (suffix Z) or include timezone information, as defined in RFC 3339 [20]. In the absence of a specified value, a default timeout of 15 minutes must be considered for the Single Authorization Message Flow and 48 hours for the Multiple Authorizations Message Flow. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 71-9 April 2013

72 Mult Element Format/Type Description [0..n] +++ other elements any Allows inclusion of additional customized element(s). [0..1] ++ extended-data [0..n] +++ other elements any Allows inclusion of additional customized elements. [1..1] ++ message anytype e-mandate request message. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 72-9 April 2013

73 5.2.2 eom-msg-rs-to-vs-001 The message type eom-msg-rs-to-vs-001 is generated and sent by Routing Services to Validation Services in order to route the e-mandate request data. The data elements that compose this message type are detailed in Table 8 and the corresponding XML schema is presented in annex A.4. Table 8: Description of message eom-msg-rs-to-vs-001 Mult Element Format/Type Description [1..1] eom-msg-rs-to-vs-001 [1..1] + header [1..1] + header@version string [1..1] ++ date datetime [1..1] ++ service Service [1..1] ++ operation Operation Version of message format. Usage Rule: Must have the value 1.1. Message timestamp. Usage Rule: Current date and time of generation of the message. Must be in UTC (suffix Z) or include timezone information, as defined in RFC 3339 [20]. Service identification tip. Usage Rule: must have the value mandate. Operation identification tip. Usage Rule: Must have the value proposal. [1..1] + payload [1..1] ++ eom-data [1..1] +++ vs-address string [1..1] +++ vs-address@type string [1..1] +++ creditor-id ReferenceID [1..1] +++ creditor-request-id ReferenceID Addressing information of the Validation Service. Usage Rule: The Bank Identifier Code (BIC) of the Debtor Bank. Must have the same value as element vs-address of eom-msg-cred-to-rs-001 Type of addressing information of the Validation Service. Usage Rule: Must have the value BIC, the same value as attribute type of element vs-address of eom-msg-credto-rs-001 Identification of the Creditor requesting the e-mandate. Usage Rule: Must have the same value as element creditor-id of eom-msg-cred-to-rs-001 Creditor s request identifier. Usage Rule: Must have the same value as element creditor-request-id of eom-msg-cred-to-rs-001 EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 73-9 April 2013

74 Mult Element Format/Type Description [1..1] +++ creditor-return-url URL [1..1] +++ due-date datetime [1..1] ++ message anytype Creditor s website URL for later redirection of the Debtor s browser back to Creditor. Usage Rule: Must have the same value as element creditor-return-url of eom-msg-cred-to-rs-001 Maximum allowed date set by the Creditor for the whole transaction to be completed before it is discarded. Usage Rule: Must be in UTC (suffix Z) or include timezone information, as defined in RFC 3339 [20]. Must have the same value as element due-date of eom-msgcred-to-rs-001 if present. e-mandate request message. Usage Rule: Must have the same content as element message of eom-msg-cred-to-rs-001 EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 74-9 April 2013

75 5.2.3 eom-msg-vs-to-rs-001 The message type eom-msg-vs-to-rs-001 is generated and sent by Validation Services to Routing Services in order to return operational data or report errors. The data elements that compose this message type are detailed in Table 9 and the corresponding XML schema is presented in annex A.5. Table 9: Description of message eom-msg-vs-to-rs-001 Mult Element Format/Type Description [1..1] eom-msg-vs-to-rs-001 [1..1] + header [1..1] + header@version string [1..1] ++ date datetime [1..1] ++ service Service [1..1] ++ operation Operation Version of message format. Usage Rule: Must have the value 1.1. Message timestamp. Usage Rule: Current date and time of generation of the message. Must be in UTC (suffix Z) or include timezone information, as defined in RFC 3339 [20]. Service identification tip. Usage Rule: Must have value mandate. Operation identification tip. Usage Rule: Must have value proposal. [1..1] + payload [1..1] ++ status int Response status. Usage Rule: Values restricted to 0 (meaning OK ) or the error codes defined in section 5.3. {Or ++ eom-data Usage Rule: This element must be present if status value is 0 (OK). [1..1] +++ creditor-id ReferenceID [1..1] +++ creditor-request-id ReferenceID {Or +++ vs-url URL Identification of the Creditor requesting the e-mandate. Usage Rule: Must have the same value as element creditor-id of eom-msg-rs-to-vs-001 Creditor s request identifier. Usage Rule: Must have the same value as element creditor-request-id of eom-msg-rs-to-vs-001 Validation Service s website URL (specific to this transaction) which will be used to redirect the Debtor s browser. Usage Rule: Must be used if the Validation Service chooses to use the Single Authorization Message Flow. Must contain sufficient HTTP GET parameters to be able to resume the transaction at a later step. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 75-9 April 2013

76 Mult Element Format/Type Description Or} +++ vs-mandate-ref ReferenceID Reference assigned by the Validation Service for the e- Mandate request to be used by the account holders of the Debtor to authorize it. Usage Rule: Must be used if the Validation Service chooses to use the Multiple Authorizations Message Flow.. Or} ++ error-details Usage Rule: This element must be present if status value is different from 0. [0..1] +++ description string [0..1] +++ hint string Error description. Usage Rule: Information that may compromise security must not be disclosed. Language used must be English. Hint about the cause of the problem. Usage Rule: Information that may compromise security must not be disclosed. Language used must be English. [0..1] +++ message anytype e-mandate error message. [0..1] +++ src-message NestedMessage Original message eom-msg-rs-to-vs-001 received by the Validation Service. Usage Rule: If the element is to be used, the original message must be included unmodified. [0..n] +++ other elements any Allows inclusion of additional customized element(s). EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 76-9 April 2013

77 5.2.4 eom-msg-rs-to-cred-001 The message type eom-msg-rs-to-cred-001 is generated and sent by Routing Services to Creditors in order to return operational data or report errors. The data elements that compose this message type are detailed in Table 10 and the corresponding XML schema is presented in annex A.6. Table 10: Description of message eom-msg-rs-to-cred-001 Mult Element Format/Type Description [1..1] eom-msg-rs-to-cred-001 [1..1] + header [1..1] + header@version string [1..1] ++ date datetime [1..1] ++ service Service [1..1] ++ operation Operation Version of message format. Usage Rule: Must have the value 1.1. Message timestamp. Usage Rule: Current date and time of generation of the message. Must be in UTC (suffix Z) or include timezone information, as defined in RFC 3339 [20]. Service identification tip. Usage Rule: Must have the value mandate. Operation identification tip. Usage Rule: Must have the value proposal. [1..1] + payload [1..1] ++ status int Response status. Usage Rule: Values restricted to 0 (meaning OK ) or the error codes defined in section 5.3. {Or ++ eom-data Usage Rule: This element must be present if status value is 0 (OK). [1..1] +++ creditor-id ReferenceID [1..1] +++ creditor-request-id ReferenceID {Or +++ vs-url URL Identification of the Creditor requesting the e-mandate. Usage Rule: Must have the same value as element creditor-id of eom-msg-vs-to-rs-001 Creditor s request identifier. Usage Rule: Must have the same value as element creditor-request-id of eom-msg-vs-to-rs-001 Validation Service s website URL (specific to this transaction) which will be used to redirect Debtor s browser. If present, it means that the Validation Service has chosen to use the Single Authorization Message Flow. Usage Rule: Must have the same value as element vs-url of eom-msg-vs-to-rs-001 EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 77-9 April 2013

78 Mult Element Format/Type Description Or} +++ vs-mandate-ref ReferenceID Reference assigned by the Validation Service for the e- Mandate request to be used by the account holders of the Debtor to authorize it. If present, it means that the Validation Service has chosen to use the Multiple Authorizations Message Flow. Usage Rule: Must have the same value as element vsmandate-ref of eom-msg-vs-to-rs-001. [0..n] +++ other elements any Allows inclusion of additional customized elements. Or} ++ error-details Usage Rule: This element must be present if status value is different from 0. [0..1] +++ description string [0..1] +++ hint string [0..1] +++ message anytype [0..1] +++ src-message NestedMessage Error description. Usage Rule: Information that may compromise security must not be disclosed. Language used must be English. Hint about the cause of the problem. Usage Rule: Information that may compromise security must not be disclosed. Language used must be English. e-mandate error message. Usage Rule: If the element is to be used, the e-mandate error message received in eom-msg-vs-to-rs-001 must be included unmodified. Original message eom-msg-cred-to-rs-001 received by the Routing Service. Usage Rule: If the element is to be used, the original message must be included unmodified. [0..n] +++ other elements any Allows inclusion of additional customized elements. [0..1] ++ extended-data [0..n] +++ other elements any Allows inclusion of additional customized elements. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 78-9 April 2013

79 5.2.5 eom-msg-cred-to-rs-002 The message type eom-msg-cred-to-rs-002 is generated and sent by Creditors to Routing Services in order to retrieve an e-mandate. The data elements that compose this message type are detailed below in Table 11 and the corresponding XML schema is presented in annex A.7. Table 11: Description of message eom-msg-cred-to-rs-002 Mult Element Format/Type Description [1..1] eom-msg-cred-to-rs-002 [1..1] + header [1..1] + header@version string [1..1] ++ date datetime [1..1] ++ service Service [1..1] ++ operation Operation Version of message format. Usage Rule: Must have the value 1.1. Message timestamp. Usage Rule: Current date and time of generation of the message. Must be in UTC (suffix Z) or include timezone information, as defined in RFC 3339 [20]. Service identification tip. Usage Rule: Must have the value mandate. Operation identification tip. Usage Rule: Must have the value retrieval to retrieve the e-mandate or acknowledge to acknowledge the reception of the e-mandate. [1..1] + payload [1..1] ++ eom-data [1..1] +++ creditor-id ReferenceID [1..1] +++ creditor-request-id ReferenceID Identification of the Creditor requesting the e-mandate. Usage Rule: Must have the same value as element creditor-id of eom-msg-cred-to-rs-001 Creditor s request identifier. Usage Rule: Must have the same value as element creditor-request-id of eom-msg-cred-to-rs-001 [0..n] +++ other elements any Allows inclusion of additional customized elements. [0..1] ++ extended-data [0..n] +++ other elements any Allows inclusion of additional customized elements. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 79-9 April 2013

80 5.2.6 eom-msg-rs-to-vs-002 The message type eom-msg-rs-to-vs-002 is generated and sent by Creditors to Routing Services in order to retrieve an e-mandate. The data elements that compose this message type are detailed below in Table 12 and the corresponding XML schema is presented in annex A.8. Table 12: Description of message eom-msg-rs-to-vs-002 Mult Element Format/Type Description [1..1] eom-msg-rs-to-vs-002 [1..1] + header [1..1] + header@version string [1..1] ++ date datetime [1..1] ++ service Service [1..1] ++ operation Operation Version of message format. Usage Rule: Must have the value 1.1. Message timestamp. Usage Rule: Current date and time of generation of the message. Must be in UTC (suffix Z) or include timezone information, as defined in RFC 3339 [20]. Service identification tip. Usage Rule: Must have the value mandate. Operation identification tip. Usage Rule: Must have the value retrieval to retrieve the e-mandate or acknowledge to acknowledge the reception of the e-mandate. [1..1] + payload [1..1] ++ data [1..1] +++ creditor-id ReferenceID [1..1] +++ creditor-request-id ReferenceID Identification of the Creditor requesting the e-mandate. Usage Rule: Must have the same value as element creditor-id of eom-msg-cred-to-rs-002 Creditor s request identifier. Usage Rule: Must have the same value as element creditor-request-id of eom-msg-cred-to-rs- 002 EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 80-9 April 2013

81 5.2.7 eom-msg-vs-to-rs-002 The message type eom-msg-vs-to-rs-002 is generated and sent by Routing Services to Validation Services in order to return an e-mandate. The data elements that compose this message type are detailed below in Table 13 and the corresponding XML schema is presented in annex A.9. Table 13: Description of message eom-msg-vs-to-rs-002 Mult Element Format/Type Description [1..1] eom-msg-vs-to-rs-002 [1..1] + header [1..1] + header@version string [1..1] ++ date datetime [1..1] ++ service Service [1..1] ++ operation Operation Version of message format. Usage Rule: Must have the value 1.1. Message timestamp. Usage Rule: Current date and time of generation of the message. Must be in UTC (suffix Z) or include timezone information, as defined in RFC 3339 [20]. Service identification tip. Usage Rule: Must have the value mandate. Operation identification tip. Usage Rule: Must have the value retrieval. [1..1] + payload [1..1] ++ status int Response status. Usage Rule: Values restricted to 0 (meaning OK ) or the error codes defined in section 5.3. {Or ++ eom-data Usage Rule: This element must be present if status value is 0 (OK). [1..1] +++ creditor-id ReferenceID [1..1] +++ creditor-request-id ReferenceID [1..1] +++ signed-message XmlSignature Identification of the Creditor requesting the e-mandate. Usage Rule: Must have the same value as element creditor-id of eom-msg-rs-to-vs-002 Creditor s request identifier. Usage Rule: Must have the same value as element creditor-request-id of eom-msg-rs-to-vs-002 e-mandate with an enveloping XML signature. Usage Rule: XML signature must be compliant with XAdES-BES. Or} ++ error-details Usage Rule: This element must be present if status value is different from 0. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 81-9 April 2013

82 Mult Element Format/Type Description [0..1] +++ description string [0..1] +++ hint string Error description. Usage Rule: Information that may compromise security must not be disclosed. Language used must be English. Hint about the cause of the problem. Usage Rule: Information that may compromise security must not be disclosed. Language used must be English. [0..1] +++ message anytype e-mandate error message. [0..1] +++ src-message NestedMessage Original message eom-msg-rs-to-vs-002 received by the Validation Service. Usage Rule: If the element is to be used, the original message must be included unmodified. [0..n] +++ other elements any Allows inclusion of additional customized elements. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 82-9 April 2013

83 5.2.8 eom-msg-rs-to-cred-002 The message type eom-msg-rs-to-cred-002 is generated and sent by Routing Services to Creditors in order to return an e-mandate. The data elements that compose this message type are detailed below in Table 14 and the corresponding XML schema is presented in annex A.10. Table 14: Description of message eom-msg-rs-to-cred-002 Mult Element Format/Type Description [1..1] eom-msg-rs-to-cred-002 [1..1] + header [1..1] + header@version string [1..1] ++ date datetime [1..1] ++ service Service [1..1] ++ operation Operation Version of message format. Usage Rule: Must have the value 1.1. Message timestamp. Usage Rule: Current date and time of generation of the message. Must be in UTC (suffix Z) or include timezone information, as defined in RFC 3339 [20]. Service identification tip. Usage Rule: Must have the value mandate. Operation identification tip. Usage Rule: Must have the value retrieval. [1..1] + payload [1..1] ++ status int Response status. Usage Rule: Values restricted to 0 (meaning OK ) or the error codes defined in section 5.3. {Or ++ eom-data Usage Rule: This element must be present if status value is 0 (OK). [1..1] +++ creditor-id ReferenceID [1..1] +++ creditor-request-id ReferenceID [1..1] +++ signed-message XmlSignature Identification of the Creditor requesting the e-mandate. Usage Rule: Must have the same value as element creditor-id of eom-msg-cred-to-rs-002 Creditor s request identifier. Usage Rule: Must have the same value as element creditor-request-id of eom-msg-cred-to-rs- 002 e-mandate with an enveloping XML signature. Usage Rule: XML signature must be compliant with XAdES-BES. [0..n] +++ other elements any Allows inclusion of additional customized element(s). EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 83-9 April 2013

84 Mult Element Format/Type Description Or} ++ error-details Usage Rule: This element must be present if status value is different from 0. [0..1] +++ description string [0..1] +++ hint string [0..1] +++ message anytype [0..1] +++ src-message NestedMessage Error description. Usage Rule: Information that may compromise security must not be disclosed. Language used must be English. Hint about the cause of the problem. Usage Rule: Information that may compromise security must not be disclosed. Language used must be English. e-mandate error message. Usage Rule: If the element is to be used, the e-mandate error message received in eom-msg-vs-to-rs-001 must be included unmodified. Original message eom-msg-vs-to-rs-002 received by the Routing Service. Usage Rule: If the element is to be used, the original message must be included unmodified. [0..n] +++ other elements any Allows inclusion of additional customized element(s). EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 84-9 April 2013

85 5.3 Error codes This section presents a list of codes for possible errors to be used on the EPC e-operating Model response messages, namely: eom-msg-vs-to-rs-001 eom-msg-rs-to-cred-001 eom-msg-vs-to-rs-002 eom-msg-rs-to-cred-002 The error codes are listed in Table 15. The four rightmost columns indicate which response messages may report the identified errors. Table 15: Error codes Code Name Reason eom-msg-vs-to-rs-001 eom-msg-rs-to-cred-001 eom-msg-vs-to-rs-002 eom-msg-rs-to-cred GenericError Generic error. X X X X 101 BusinessError A specific error at the business level has occurred. X X X X 102 InternalServerError Internal server error. X X X X 103 UnkownError An unknown error has occurred. X X X X 104 OperationTimeout The defined transaction timeout was reached. X X X X 105 MissedDueDate The due date defined by the Creditor was reached. X X X X 106 BrokenSession The communication session was abruptly closed. X X X X 107 ErrorOnValidationService The Validation Service has returned an error. X X 108 UnavailableValidationService Routing Service failed to connect to the Validation Service. X X 200 GenericDataError Data provided has one or more errors. X X X X 201 BadFormedXML The XML message is not a well formed XML document. X X X X 202 InvalidXML The XML message is not valid according to the corresponding XML schema. X X X X 203 InvalidCharacterSet The message character is invalid or unspecified. X X X X 204 IncompleteData One or more data elements are missing. X X X X 205 BadFormatData One or more data elements are incorrectly formatted. X X X X 206 InvalidService The requested service is unknown or not supported. X X X X 207 ServiceNotAllowed The requester is not allowed to use this service. X X X X 208 InvalidOperation The requested operation is unknown or not supported. X X X X 209 OperationNotAllowed The requester is not allowed to use this operation. X X X X 210 InvalidVersion This message version is not supported. X X X X 211 BankIdentifierIncorrect Bank identifier incorrect (i.e. invalid BIC). X 212 InvalidCreditorID Invalid or incorrect Creditor ID. X X 213 IlegitimateCreditorID The Creditor ID does not correspond to the authenticated Creditor. X X 214 InvalidCreditorRequestID This request identifier has already been used by this Creditor. X X 215 InvalidValidationServiceRequestID This request identifier is invalid or unknown to the Validation Service. X 216 BadFormedURL The received URL is not a well formed URL. X X EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 85-9 April 2013

86 Code Name Reason eom-msg-vs-to-rs-001 eom-msg-rs-to-cred-001 eom-msg-vs-to-rs-002 eom-msg-rs-to-cred BicResolutionError An error has occurred when trying to resolve the BIC. X 218 WrongValidationServiceForBic The BIC provided does not correspond to the resolved Validation Service. X 300 GeneralAuthenticationFailure A general error occurred while performing an authentication. X X X X 301 DebtorAuthenticationFailed Debtor did not present the correct authentication means to the Validation Service. X X 302 DebtorAuthorizationFailed Debtor has not authorized the e-mandate. X X 303 InvalidRSAuthenticationCredentials Invalid authentication credentials presented by the Routing Service. X X 400 GeneralCryptographicError A general error occurred while performing a cryptographic operation. X X X X 401 WeakCipherSuites The system does not support the minimum cryptographic algorithm and/or the minimum key length needed to establish a X X X X secure connection. 402 InvalidElectronicSignature Invalid electronic signature of the e-mandate. X 403 InvalidDigestValue Invalid digest value on the electronic signature of the e- Mandate. X 404 IncompleteCertificateChain The certificate chain does not include all the certificates necessary to reach a trusted Root CA. X X X X 405 RevokedCertificate The certificate has been revoked. X X X X 406 ExpiredCertficate The certificate expiration date has been reached. X X X X 407 NotYetValidCertificate The initial validity date of the certificate is later than the current date. X X X X 408 InvalidCertificateChain At least one of the certificates in this certificate chain is invalid (i.e. is revoked, expired, not yet valid, etc.). X X X X 409 InvalidCertificate The certificate is invalid (i.e. it's revoked, expired, is not valid yet, etc.). X X X X 410 UntrustedCertificate The certificate has not been issued or signed by a trusted CA. X X X X 411 UntrustedCertificateChain A trusted certificate chain could not be achived for the X X X X certificate. 412 InvalidCertificateUsage The certificate does not include a valid "key usage" and/or policy to the aim which it is intended to be used. X X X X 413 CantCheckCertificateStatus Could not get the certificate status information, i.e., could not contact the corresponding OCSP server or get an updated CRL. X X X X 414 UnsupportedCryptoAlgorithm The cryptographic algorithm is not formatted. X X X X The error codes listed above in Table 15 are to be used on the status element of EPC e- Operating Model response messages. A value of 0 (zero) means successful processing while any other value indicates that an error has occurred. The BusinessError code is used to encapsulate errors occurred at the specific business logic layer. The returning business error message must be nested under the message element in errordetails, while the original EPC e-operating Model message is recommended to be nested under the src-message element. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 86-9 April 2013

87 For security reasons, parties receiving errors from other parties must not forward any error details to any other party that may be holding for a response. This means that a Routing Service provider must not forward EPC e-operatingmodel error codes and possible descriptions and hints returned by Validation Services to holding Creditors. In this situation, it is appropriate to return an ErrorOnValidationService error code. Equivalently, a Creditor must not display any EPC e- OperatingModel error codes and possible descriptions and hints returned by Routing Services to holding Debtors. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 87-9 April 2013

88 6 TERMS USED IN THE DOCUMENT Term Adherence Agreement Bank Identifier Code (BIC) BIC Certificate Certificate Revocation List Certification Authority Definition The agreement to be completed as part of the process by which an entity applies to become a Participant. An 8 or 11 character ISO code assigned by SWIFT and used to identify a financial institution in financial transactions (ISO 9362). See Bank Identifier Code. Public key of a user, together with some other information, rendered unforgeable by encipherment with the private key of the certification authority which issued it [30]. A signed list of revoked certificates periodically issued by a Certification Authority. Entity trusted by one or more users to create and assign certificates. Creditor Defined in [3]. Creditor Bank Defined in [3]. CRL See Certificate Revocation List. Debtor Defined in [3]. Debtor Bank Defined in section [3]. Directory Service Defined in section [3]. Disclosure EPC EPC Approved Certification Authority HTTP HTTPS IBAN OCSP Disclosure occurs when sensitive data is retrieved by persons which are not supposed to have access to it. The European Payments Council ( A Certification Authority compliant with the requirements defined by the EPC. Hypertext Transfer Protocol. Hypertext Transfer Protocol over TLS. An expanded version of the basic bank account number (BBAN) intended for use internationally that uniquely identifies an individual account at a specific financial institution in a particular country (ISO 13616, EBS 204). As of late-2005, ISO is in the process of aligning the ISO Standard with the European Standard EBS 204. In due course the ISO Standard will replace the EBS standard. See Online Certificate Status Protocol. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 88-9 April 2013

89 Term Online Certificate Status Protocol Operational BIC PKI Repudiation Routing Service Routing Service Providers SDD SEPA Direct Debit Scheme SEPA Direct Debit Scheme Rulebook Tampering TLS URL Validation Service Validation Service Providers W3C XML Definition A protocol designed to verify the current status of a given certificate. Is the BIC that the Debtor receives from the Debtor Bank. Public Key Infrastructure. Repudiation occurs when someone claims to have not performed a disputed operation that he actually performed. Reversely, repudiation is also about being able to refute the validity of forged operations. Defined [3]. For the sake of simplicity, the terms Routing Service and Routing Service Provider may be used interchangeably throughout this document. See Routing Service. See SEPA Direct Debit Scheme. The SEPA Direct Debit Scheme is the payments scheme for making direct debits across SEPA, as set out in the SEPA Direct Debit Scheme Rulebook. The Rulebook setting out rules and business standards for the SEPA Direct Debit Scheme. An attack in which data is modified or corrupted while in transit between two parties. Transport Layer Security. Uniform Resource Locator. Defined in [3]. For the sake of simplicity, the terms Validation Service and Validation Service Provider may be used interchangeably throughout this document. See Validation Service. World Wide Web Consortium ( Extensible Markup Language. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 89-9 April 2013

90 ANNEX A XML SCHEMAS The set of XML messages defined for the EPC e-operating Model are described on XML schemas oriented to a modular and flexible design. The messages are segmented in several schemas which make use of the include and import schema mechanisms. Figure 20 illustrates the relationships between the different XML schema modules. Figure 20: XML schema modules for the EPC e-operating Model The target namespace set for this version of the e-operating Model schemas is A.1 eom-common.xsd <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" xmlns=" elementformdefault="qualified" targetnamespace=" <xs:complextype name="message" abstract="true"> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 90-9 April 2013

91 <xs:annotation> <xs:documentation>common message skeleton for all EPC e-operating Model messages.</xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="header" type="header"/> </xs:sequence> </xs:complextype> <xs:complextype name="payload" abstract="true"/> <xs:complextype name="header"> <xs:sequence> <xs:element name="date" type="xs:datetime"/> <xs:element name="service" type="service"/> <xs:element name="operation" type="operation"/> </xs:sequence> <xs:attribute name="version" type="xs:string" use="required"/> </xs:complextype> <xs:simpletype name="service"> <xs:restriction base="xs:string"/> </xs:simpletype> <xs:simpletype name="operation"> <xs:restriction base="xs:string"/> </xs:simpletype> <xs:complextype name="vsaddress"> <xs:simplecontent> <xs:extension base="xs:string"> <xs:attribute name="type" type="xs:string" use="required"/> </xs:extension> </xs:simplecontent> </xs:complextype> <xs:simpletype name="referenceid"> <xs:restriction base="xs:string"> <xs:minlength value="1"/> <xs:maxlength value="256"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="url"> <xs:restriction base="xs:anyuri"> <xs:minlength value="1"/> <xs:maxlength value="2048"/> </xs:restriction> </xs:simpletype> <xs:complextype name="extendeddata"> <xs:sequence> <xs:any namespace="##other" processcontents="skip" minoccurs="0" maxoccurs="unbounded"/> </xs:sequence> </xs:complextype> <xs:complextype name="nestedmessage"> <xs:sequence> <xs:any namespace=" processcontents="skip"/> </xs:sequence> </xs:complextype> <xs:complextype name="xmlsignature"> <xs:sequence> <xs:any namespace=" processcontents="skip"/> </xs:sequence> </xs:complextype> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 91-9 April 2013

92 77 78 </xs:schema> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 92-9 April 2013

93 A.2 eom-status.xsd <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" xmlns=" elementformdefault="qualified" targetnamespace=" <xs:include schemalocation="eom-common.xsd"/> <xs:complextype name="errordetails"> <xs:sequence> <xs:element name="description" type="xs:string" minoccurs="0" maxoccurs="1"/> <xs:element name="hint" type="xs:string" minoccurs="0" maxoccurs="1"/> <xs:element name="message" type="nestedmessage" minoccurs="0" maxoccurs="1"/> <xs:element name="src-message" type="nestedmessage" minoccurs="0" maxoccurs="1"/> <xs:any namespace="##other" processcontents="skip" minoccurs="0" maxoccurs="unbounded"/> </xs:sequence> </xs:complextype> </xs:schema> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 93-9 April 2013

94 A.3 eom-msg-cred-to-rs-001.xsd Figure 21: Graphical XML schema of message eom-msg-cred-to-rs <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" xmlns=" elementformdefault="qualified" targetnamespace=" <xs:annotation> <xs:documentation> e-operating Model message cred-to-rs-001, to be sent by Creditors to Routing Services. </xs:documentation> </xs:annotation> <xs:include schemalocation="eom-common.xsd"/> <xs:element name="eom-msg-cred-to-rs-001" type="messagecredtors001"/> <xs:complextype name="messagecredtors001"> <xs:complexcontent> <xs:extension base="message"> <xs:sequence> <xs:element name="payload" type="payloadcredtors001"/> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 94-9 April 2013

95 <xs:complextype name="payloadcredtors001"> <xs:complexcontent> <xs:extension base="payload"> <xs:sequence> <xs:element name="eom-data" type="datacredtors001"/> <xs:element name="extended-data" type="extendeddata" minoccurs="0" maxoccurs="1"/> <xs:element name="message" type="xs:anytype"/> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> <xs:complextype name="datacredtors001"> <xs:sequence> <xs:element name="vs-address" type="vsaddress"/> <xs:element name="creditor-id" type="referenceid"/> <xs:element name="creditor-request-id" type="referenceid"/> <xs:element name="creditor-return-url" type="url"/> <xs:element name="due-date" type="xs:datetime" minoccurs="0" maxoccurs="1"/> <xs:any namespace="##other" processcontents="skip" minoccurs="0" maxoccurs="unbounded"/> </xs:sequence> </xs:complextype> </xs:schema> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 95-9 April 2013

96 A.4 eom-msg-rs-to-vs-001.xsd Figure 22: Graphical XML schema of message eom-msg-rs-to-vs <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" xmlns=" elementformdefault="qualified" targetnamespace=" <xs:annotation> <xs:documentation> e-operating Model message rs-to-vs-001, to be sent by Routing Services to Validation Services. </xs:documentation> </xs:annotation> <xs:include schemalocation="eom-common.xsd"/> <xs:element name="eom-msg-rs-to-vs-001" type="messagerstovs001"/> <xs:complextype name="messagerstovs001"> <xs:complexcontent> <xs:extension base="message"> <xs:sequence> <xs:element name="payload" type="payloadrstovs001"/> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> <xs:complextype name="payloadrstovs001"> <xs:complexcontent> <xs:extension base="payload"> <xs:sequence> <xs:element name="eom-data" type="datarstovs001"/> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 96-9 April 2013

97 <xs:element name="message" type="xs:anytype"/> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> <xs:complextype name="datarstovs001"> <xs:sequence> <xs:element name="vs-address" type="vsaddress"/> <xs:element name="creditor-id" type="referenceid"/> <xs:element name="creditor-request-id" type="referenceid"/> <xs:element name="creditor-return-url" type="url"/> <xs:element name="due-date" type="xs:datetime" minoccurs="0" maxoccurs="1"/> </xs:sequence> </xs:complextype> </xs:schema> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 97-9 April 2013

98 A.5 eom-msg-vs-to-rs-001.xsd Figure 23: Graphical XML schema of message eom-msg-vs-to-rs <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" xmlns=" elementformdefault="qualified" targetnamespace=" <xs:annotation> <xs:documentation> e-operating Model message vs-to-rs-001, to be sent by Validation Services to Routing Services. </xs:documentation> </xs:annotation> <xs:include schemalocation="eom-common.xsd"/> <xs:include schemalocation="eom-status.xsd"/> <xs:element name="eom-msg-vs-to-rs-001" type="messagevstors001"/> <xs:complextype name="messagevstors001"> <xs:complexcontent> <xs:extension base="message"> <xs:sequence> <xs:element name="payload" type="payloadvstors001"/> </xs:sequence> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 98-9 April 2013

99 </xs:extension> </xs:complexcontent> </xs:complextype> <xs:complextype name="payloadvstors001"> <xs:sequence> <xs:element name="status" type="statuscodevstors001"/> <xs:choice> <xs:element name="eom-data" type="datavstors001"/> <xs:element name="error-details" type="errordetails"/> </xs:choice> </xs:sequence> </xs:complextype> <xs:complextype name="datavstors001"> <xs:sequence> <xs:element name="creditor-id" type="referenceid"/> <xs:element name="creditor-request-id" type="referenceid"/> <xs:choice> <xs:element name="vs-url" type="url"/> <xs:element name="vs-mandate-ref" type="referenceid"/> </xs:choice> </xs:sequence> </xs:complextype> <xs:simpletype name="statuscodevstors001"> <xs:restriction base="xs:int"> <xs:enumeration value="0"/> <!-- OK --> <xs:enumeration value="100"/> <!-- GenericError --> <xs:enumeration value="101"/> <!-- BusinessError --> <xs:enumeration value="102"/> <!-- InternalServerError --> <xs:enumeration value="103"/> <!-- UnkownError --> <xs:enumeration value="104"/> <!-- OperationTimeout --> <xs:enumeration value="105"/> <!-- BrokenSession --> <xs:enumeration value="200"/> <!-- GenericDataError --> <xs:enumeration value="201"/> <!-- BadFormedXML --> <xs:enumeration value="202"/> <!-- InvalidXML --> <xs:enumeration value="203"/> <!-- InvalidCharacterSet --> <xs:enumeration value="204"/> <!-- IncompleteData --> <xs:enumeration value="205"/> <!-- BadFormatData --> <xs:enumeration value="206"/> <!-- InvalidService --> <xs:enumeration value="207"/> <!-- ServiceNotAllowed --> <xs:enumeration value="208"/> <!-- InvalidOperation --> <xs:enumeration value="209"/> <!-- OperationNotAllowed --> <xs:enumeration value="210"/> <!-- InvalidVersion --> <xs:enumeration value="216"/> <!-- BadFormedURL --> <xs:enumeration value="218"/> <!-- WrongValidationServiceForBic --> <xs:enumeration value="300"/> <!-- GeneralAuthenticationFailure --> <xs:enumeration value="303"/> <!-- InvalidRSAuthenticationCredentials --> <xs:enumeration value="400"/> <!-- GeneralCryptographicError --> <xs:enumeration value="401"/> <!-- WeakCipherSuites --> <xs:enumeration value="404"/> <!-- IncompleteCertificateChain --> <xs:enumeration value="405"/> <!-- RevokedCertificate --> <xs:enumeration value="406"/> <!-- ExpiredCertficate --> <xs:enumeration value="407"/> <!-- NotYetValidCertificate --> <xs:enumeration value="408"/> <!-- InvalidCertificateChain --> <xs:enumeration value="409"/> <!-- InvalidCertificate --> <xs:enumeration value="410"/> <!-- UntrustedCertificate --> <xs:enumeration value="411"/> <!-- UntrustedCertificateChain --> <xs:enumeration value="412"/> <!-- InvalidCertificateUsage --> <xs:enumeration value="413"/> <!-- CantCheckCertificateStatus --> <xs:enumeration value="414"/> <!-- UnsupportedCryptoAlgorithm --> </xs:restriction> </xs:simpletype> </xs:schema> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page 99-9 April 2013

100 A.6 eom-msg-rs-to-cred-001.xsd Figure 24: Graphical XML schema of message eom-msg-rs-to-cred <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" xmlns=" elementformdefault="qualified" targetnamespace=" <xs:annotation> <xs:documentation> e-operating Model message rs-to-cred-001, to be sent by Routing Services to Creditors. </xs:documentation> </xs:annotation> <xs:include schemalocation="eom-common.xsd"/> <xs:include schemalocation="eom-status.xsd"/> <xs:element name="eom-msg-rs-to-cred-001" type="messagerstocred001"/> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page April 2013

101 <xs:complextype name="messagerstocred001"> <xs:complexcontent> <xs:extension base="message"> <xs:sequence> <xs:element name="payload" type="payloadrstocred001"/> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> <xs:complextype name="payloadrstocred001"> <xs:sequence> <xs:element name="status" type="statuscoderstocred001"/> <xs:choice> <xs:element name="eom-data" type="datarstocred001"/> <xs:element name="error-details" type="errordetails"/> </xs:choice> <xs:element name="extended-data" type="extendeddata" minoccurs="0" maxoccurs="1"/> </xs:sequence> </xs:complextype> <xs:complextype name="datarstocred001"> <xs:sequence> <xs:element name="creditor-id" type="referenceid"/> <xs:element name="creditor-request-id" type="referenceid"/> <xs:choice> <xs:element name="vs-url" type="url"/> <xs:element name="vs-mandate-ref" type="referenceid"/> </xs:choice> <xs:any namespace="##other" processcontents="skip" minoccurs="0" maxoccurs="unbounded"/> </xs:sequence> </xs:complextype> <xs:simpletype name="statuscoderstocred001"> <xs:restriction base="xs:int"> <xs:enumeration value="0"/> <!-- OK --> <xs:enumeration value="100"/> <!-- GenericError --> <xs:enumeration value="101"/> <!-- BusinessError --> <xs:enumeration value="102"/> <!-- InternalServerError --> <xs:enumeration value="103"/> <!-- UnkownError --> <xs:enumeration value="104"/> <!-- OperationTimeout --> <xs:enumeration value="105"/> <!-- BrokenSession --> <xs:enumeration value="106"/> <!-- ErrorOnValidationService --> <xs:enumeration value="107"/> <!-- UnavailableValidationService --> <xs:enumeration value="200"/> <!-- GenericDataError --> <xs:enumeration value="201"/> <!-- BadFormedXML --> <xs:enumeration value="202"/> <!-- InvalidXML --> <xs:enumeration value="203"/> <!-- InvalidCharacterSet --> <xs:enumeration value="204"/> <!-- IncompleteData --> <xs:enumeration value="205"/> <!-- BadFormatData --> <xs:enumeration value="206"/> <!-- InvalidService --> <xs:enumeration value="207"/> <!-- ServiceNotAllowed --> <xs:enumeration value="208"/> <!-- InvalidOperation --> <xs:enumeration value="209"/> <!-- OperationNotAllowed --> <xs:enumeration value="210"/> <!-- InvalidVersion --> <xs:enumeration value="211"/> <!-- BankIdentifierIncorrect --> <xs:enumeration value="212"/> <!-- InvalidCreditorID --> <xs:enumeration value="213"/> <!-- IlegitimateCreditorID --> <xs:enumeration value="214"/> <!-- InvalidCreditorRequestID --> <xs:enumeration value="216"/> <!-- BadFormedURL --> <xs:enumeration value="217"/> <!-- BicResolutionError --> <xs:enumeration value="300"/> <!-- GeneralAuthenticationFailure --> <xs:enumeration value="400"/> <!-- GeneralCryptographicError --> <xs:enumeration value="401"/> <!-- WeakCipherSuites --> <xs:enumeration value="404"/> <!-- IncompleteCertificateChain --> <xs:enumeration value="405"/> <!-- RevokedCertificate --> <xs:enumeration value="406"/> <!-- ExpiredCertficate --> <xs:enumeration value="407"/> <!-- NotYetValidCertificate --> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page April 2013

102 <xs:enumeration value="408"/> <!-- InvalidCertificateChain --> <xs:enumeration value="409"/> <!-- InvalidCertificate --> <xs:enumeration value="410"/> <!-- UntrustedCertificate --> <xs:enumeration value="411"/> <!-- UntrustedCertificateChain --> <xs:enumeration value="412"/> <!-- InvalidCertificateUsage --> <xs:enumeration value="413"/> <!-- CantCheckCertificateStatus --> <xs:enumeration value="414"/> <!-- UnsupportedCryptoAlgorithm --> </xs:restriction> </xs:simpletype> </xs:schema> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page April 2013

103 A.7 eom-msg-cred-to-rs-002.xsd Figure 25: Graphical XML schema of message eom-msg-cred-to-rs <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" xmlns=" elementformdefault="qualified" targetnamespace=" <xs:annotation> <xs:documentation> e-operating Model message cred-to-rs-002, to be sent by Creditors to Routing Services. </xs:documentation> </xs:annotation> <xs:include schemalocation="eom-common.xsd"/> <xs:element name="eom-msg-cred-to-rs-002" type="messagecredtors002"/> <xs:complextype name="messagecredtors002"> <xs:complexcontent> <xs:extension base="message"> <xs:sequence> <xs:element name="payload" type="payloadcredtors002"/> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> <xs:complextype name="payloadcredtors002"> <xs:complexcontent> <xs:extension base="payload"> <xs:sequence> <xs:element name="eom-data" type="datacredtors002"/> <xs:element name="extended-data" type="extendeddata" minoccurs="0" maxoccurs="1"/> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page April 2013

104 <xs:complextype name="datacredtors002"> <xs:sequence> <xs:element name="creditor-id" type="referenceid"/> <xs:element name="creditor-request-id" type="referenceid"/> <xs:any namespace="##other" processcontents="skip" minoccurs="0" maxoccurs="unbounded"/> </xs:sequence> </xs:complextype> </xs:schema> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page April 2013

105 A.8 eom-msg-rs-to-vs-002.xsd Figure 26: Graphical XML schema of message eom-msg-rs-to-vs <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" xmlns=" elementformdefault="qualified" targetnamespace=" <xs:annotation> <xs:documentation>e-operating Model message rs-to-vs-002, to be sent by Routing Services to Validation Services.</xs:documentation> </xs:annotation> <xs:include schemalocation="eom-common.xsd"/> <xs:element name="eom-msg-rs-to-vs-002" type="messagerstovs002"/> <xs:complextype name="messagerstovs002"> <xs:complexcontent> <xs:extension base="message"> <xs:sequence> <xs:element name="payload" type="payloadrstovs002"/> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> <xs:complextype name="payloadrstovs002"> <xs:complexcontent> <xs:extension base="payload"> <xs:sequence> <xs:element name="eom-data" type="datarstovs002"/> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> <xs:complextype name="datarstovs002"> <xs:sequence> <xs:element name="creditor-id" type="referenceid"/> <xs:element name="creditor-request-id" type="referenceid"/> </xs:sequence> </xs:complextype> </xs:schema> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page April 2013

106 A.9 eom-msg-vs-to-rs-002.xsd Figure 27: Graphical XML schema of message eom-msg-vs-to-rs <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" xmlns=" elementformdefault="qualified" targetnamespace=" <xs:annotation> <xs:documentation> e-operating Model message vs-to-rs-002, to be sent by Validation Services to Routing Services. </xs:documentation> </xs:annotation> <xs:include schemalocation="eom-common.xsd"/> <xs:include schemalocation="eom-status.xsd"/> <xs:element name="eom-msg-vs-to-rs-002" type="messagevstors002"/> <xs:complextype name="messagevstors002"> <xs:complexcontent> <xs:extension base="message"> <xs:sequence> <xs:element name="payload" type="payloadvstors002"/> </xs:sequence> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page April 2013

107 </xs:extension> </xs:complexcontent> </xs:complextype> <xs:complextype name="payloadvstors002"> <xs:sequence> <xs:element name="status" type="statuscodevstors002"/> <xs:choice> <xs:element name="eom-data" type="datavstors002"/> <xs:element name="error-details" type="errordetails"/> </xs:choice> </xs:sequence> </xs:complextype> <xs:complextype name="datavstors002"> <xs:sequence> <xs:element name="creditor-id" type="referenceid"/> <xs:element name="creditor-request-id" type="referenceid"/> <xs:element name="signed-message" type="xmlsignature"/> </xs:sequence> </xs:complextype> <xs:simpletype name="statuscodevstors002"> <xs:restriction base="xs:int"> <xs:enumeration value="0"/> <!-- OK --> <xs:enumeration value="100"/> <!-- GenericError --> <xs:enumeration value="101"/> <!-- BusinessError --> <xs:enumeration value="102"/> <!-- InternalServerError --> <xs:enumeration value="103"/> <!-- UnkownError --> <xs:enumeration value="105"/> <!-- OperationTimeout --> <xs:enumeration value="106"/> <!-- BrokenSession --> <xs:enumeration value="200"/> <!-- GenericDataError --> <xs:enumeration value="201"/> <!-- BadFormedXML --> <xs:enumeration value="202"/> <!-- InvalidXML --> <xs:enumeration value="203"/> <!-- InvalidCharacterSet --> <xs:enumeration value="204"/> <!-- IncompleteData --> <xs:enumeration value="205"/> <!-- BadFormatData --> <xs:enumeration value="206"/> <!-- InvalidService --> <xs:enumeration value="207"/> <!-- ServiceNotAllowed --> <xs:enumeration value="208"/> <!-- InvalidOperation --> <xs:enumeration value="209"/> <!-- OperationNotAllowed --> <xs:enumeration value="210"/> <!-- InvalidVersion --> <xs:enumeration value="215"/> <!-- InvalidValidationServiceRequestID --> <xs:enumeration value="300"/> <!-- GeneralAuthenticationFailure --> <xs:enumeration value="301"/> <!-- DebtorAuthenticationFailed --> <xs:enumeration value="302"/> <!-- DebtorAuthorizationFailed --> <xs:enumeration value="303"/> <!-- InvalidRSAuthenticationCredentials --> <xs:enumeration value="400"/> <!-- GeneralCryptographicError --> <xs:enumeration value="401"/> <!-- WeakCipherSuites --> <xs:enumeration value="404"/> <!-- IncompleteCertificateChain --> <xs:enumeration value="405"/> <!-- RevokedCertificate --> <xs:enumeration value="406"/> <!-- ExpiredCertficate --> <xs:enumeration value="407"/> <!-- NotYetValidCertificate --> <xs:enumeration value="408"/> <!-- InvalidCertificateChain --> <xs:enumeration value="409"/> <!-- InvalidCertificate --> <xs:enumeration value="410"/> <!-- UntrustedCertificate --> <xs:enumeration value="411"/> <!-- UntrustedCertificateChain --> <xs:enumeration value="412"/> <!-- InvalidCertificateUsage --> <xs:enumeration value="413"/> <!-- CantCheckCertificateStatus --> <xs:enumeration value="414"/> <!-- UnsupportedCryptoAlgorithm --> </xs:restriction> </xs:simpletype> </xs:schema> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page April 2013

108 A.10 eom-msg-rs-to-cred-002.xsd Figure 28: Graphical XML schema of message eom-msg-rs-to-cred <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" xmlns=" elementformdefault="qualified" targetnamespace=" <xs:annotation> <xs:documentation> e-operating Model message rs-to-cred-002, to be sent by Routing Services to Creditors. </xs:documentation> </xs:annotation> <xs:include schemalocation="eom-common.xsd"/> <xs:include schemalocation="eom-status.xsd"/> <xs:element name="eom-msg-rs-to-cred-002" type="messagerstocred002"/> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page April 2013

109 <xs:complextype name="messagerstocred002"> <xs:complexcontent> <xs:extension base="message"> <xs:sequence> <xs:element name="payload" type="payloadrstocred002"/> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> <xs:complextype name="payloadrstocred002"> <xs:sequence> <xs:element name="status" type="statuscoderstocred002"/> <xs:choice> <xs:element name="eom-data" type="datarstocred002"/> <xs:element name="error-details" type="errordetails"/> </xs:choice> <xs:element name="extended-data" type="extendeddata" minoccurs="0" maxoccurs="1"/> </xs:sequence> </xs:complextype> <xs:complextype name="datarstocred002"> <xs:sequence> <xs:element name="creditor -id" type="referenceid"/> <xs:element name="creditor-request-id" type="referenceid"/> <xs:element name="signed-message" type="xmlsignature"/> <xs:any namespace="##other" processcontents="skip" minoccurs="0" maxoccurs="unbounded"/> </xs:sequence> </xs:complextype> <xs:simpletype name="statuscoderstocred002"> <xs:restriction base="xs:int"> <xs:enumeration value="0"/> <!-- OK --> <xs:enumeration value="100"/> <!-- GenericError --> <xs:enumeration value="101"/> <!-- BusinessError --> <xs:enumeration value="102"/> <!-- InternalServerError --> <xs:enumeration value="103"/> <!-- UnkownError --> <xs:enumeration value="104"/> <!-- OperationTimeout --> <xs:enumeration value="105"/> <!-- BrokenSession --> <xs:enumeration value="106"/> <!-- ErrorOnValidationService --> <xs:enumeration value="107"/> <!-- UnavailableValidationService --> <xs:enumeration value="200"/> <!-- GenericDataError --> <xs:enumeration value="201"/> <!-- BadFormedXML --> <xs:enumeration value="202"/> <!-- InvalidXML --> <xs:enumeration value="203"/> <!-- InvalidCharacterSet --> <xs:enumeration value="204"/> <!-- IncompleteData --> <xs:enumeration value="205"/> <!-- BadFormatData --> <xs:enumeration value="206"/> <!-- InvalidService --> <xs:enumeration value="207"/> <!-- ServiceNotAllowed --> <xs:enumeration value="208"/> <!-- InvalidOperation --> <xs:enumeration value="209"/> <!-- OperationNotAllowed --> <xs:enumeration value="210"/> <!-- InvalidVersion --> <xs:enumeration value="211"/> <!-- BankIdentifierIncorrect --> <xs:enumeration value="212"/> <!-- InvalidCreditorID --> <xs:enumeration value="213"/> <!-- IlegitimateCreditorID --> <xs:enumeration value="214"/> <!-- InvalidCreditorRequestID --> <xs:enumeration value="300"/> <!-- GeneralAuthenticationFailure --> <xs:enumeration value="301"/> <!-- DebtorAuthenticationFailed --> <xs:enumeration value="302"/> <!-- DebtorAuthorizationFailed --> <xs:enumeration value="400"/> <!-- GeneralCryptographicError --> <xs:enumeration value="401"/> <!-- WeakCipherSuites --> <xs:enumeration value="402"/> <!-- InvalidElectronicSignature --> <xs:enumeration value="403"/> <!-- InvalidDigestValue --> <xs:enumeration value="404"/> <!-- IncompleteCertificateChain --> <xs:enumeration value="405"/> <!-- RevokedCertificate --> <xs:enumeration value="406"/> <!-- ExpiredCertficate --> <xs:enumeration value="407"/> <!-- NotYetValidCertificate --> <xs:enumeration value="408"/> <!-- InvalidCertificateChain --> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page April 2013

110 <xs:enumeration value="409"/> <!-- InvalidCertificate --> <xs:enumeration value="410"/> <!-- UntrustedCertificate --> <xs:enumeration value="411"/> <!-- UntrustedCertificateChain --> <xs:enumeration value="412"/> <!-- InvalidCertificateUsage --> <xs:enumeration value="413"/> <!-- CantCheckCertificateStatus --> <xs:enumeration value="414"/> <!-- UnsupportedCryptoAlgorithm --> </xs:restriction> </xs:simpletype> </xs:schema> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page April 2013

111 ANNEX B XML MESSAGE SAMPLES This annex presents XML samples for the messages defined in chapter 5 and according to the schemas defined in Annex A. B.1 eom-msg-cred-to-rs-001 <?xml version="1.0" encoding="utf-8"?> <eom-msg-cred-to-rs-001 xmlns=" xmlns:xsi=" <header version="1.1"> <date> t15:00:01z</date> <service>mandate</service> <operation>proposal</operation> </header> <payload> <eom-data> <vs-address type="bic">bbarpptlxxx</vs-address> <creditor-id>pt </creditor-id> <creditor-request-id> </creditor-request-id> <creditor-return-url> 98fc03334</creditor-return-url> <due-date> t16:00:01z</due-date> </eom-data> <message> <e-mandate>...</e-mandate> </message> </payload> </eom-msg-cred-to-rs-001> B.2 eom-msg-rs-to-vs-001 <?xml version="1.0" encoding="utf-8"?> <eom-msg-rs-to-vs-001 xmlns=" xmlns:xsi=" <header version="1.1"> <date> t15:00:02z</date> <service>mandate</service> <operation>proposal</operation> </header> <payload> <eom-data> <vs-address type="bic">bbarpptlxxx</vs-address> <creditor-id>pt </creditor-id> <creditor-request-id> </creditor-request-id> <creditor-return-url> 98fc03334</creditor-return-url> <due-date> t16:00:01z</due-date> </eom-data> <message> <e-mandate>...</e-mandate> </message> </payload> </eom-msg-rs-to-vs-001> B.3 eom-msg-vs-to-rs-001 EPC e-operating Model Detailed Specification v1.2 Approved.doc Page April 2013

112 Single Authorization Message Flow <?xml version="1.0" encoding="utf-8"?> <eom-msg-vs-to-rs-001 xmlns=" xmlns:xsi=" <header version="1.1"> <date> t15:00:03z</date> <service>mandate</service> <operation>proposal</operation> </header> <payload> <status>0</status> <eom-data> <creditor-id>pt </creditor-id> <creditor-request-id> </creditor-request-id> <vs-url> </eom-data> </payload> </eom-msg-vs-to-rs-001> Multiple Authorizations Message Flow <?xml version="1.0" encoding="utf-8"?> <eom-msg-vs-to-rs-001 xmlns=" xmlns:xsi=" <header version="1.1"> <date> t15:00:03z</date> <service>mandate</service> <operation>proposal</operation> </header> <payload> <status>0</status> <eom-data> <creditor-id>pt </creditor-id> <creditor-request-id> </creditor-request-id> <vs-mandate-ref> </vs-mandate-ref> </eom-data> </payload> </eom-msg-vs-to-rs-001> B.4 Error eom-msg-vs-to-rs-001 <?xml version="1.0" encoding="utf-8"?> <eom-msg-vs-to-rs-001 xmlns=" xmlns:xsi=" <header version="1.1"> <date> t15:00:03z</date> <service>mandate</service> <operation>proposal</operation> </header> <payload> <status>100</status> <error-details> <description>internal server error</description> <hint>try again later</hint> <src-message> <eom-msg-rs-to-vs-001> <header version="1.1"> <date> t15:00:02z</date> <service>mandate</service> <operation>proposal</operation> </header> <payload> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page April 2013

113 <eom-data> <vs-address type="bic">bbarpptlxxx</vs-address> <creditor-id>pt </creditor-id> <creditor-request-id> </creditor-request-id> <creditor-return-url> 98fc03334</creditor-return-url> </eom-data> <message> <e-mandate>...</e-mandate> </message> </payload> </eom-msg-rs-to-vs-001> </src-message> </error-details> </payload> </eom-msg-vs-to-rs-001> B.5 eom-msg-rs-to-cred-001 Single Authorization Message Flow <?xml version="1.0" encoding="utf-8"?> <eom-msg-rs-to-cred-001 xmlns=" xmlns:xsi=" <header version="1.1"> <date> t15:00:04z</date> <service>mandate</service> <operation>proposal</operation> </header> <payload> <status>0</status> <eom-data> <creditor-id>pt </creditor-id> <creditor-request-id> </creditor-request-id> <vs-url> </eom-data> </payload> </eom-msg-rs-to-cred-001> MultipleAuthorizations Message Flow <?xml version="1.0" encoding="utf-8"?> <eom-msg-rs-to-cred-001 xmlns=" xmlns:xsi=" <header version="1.1"> <date> t15:00:04z</date> <service>mandate</service> <operation>proposal</operation> </header> <payload> <status>0</status> <eom-data> <creditor-id>pt </creditor-id> <creditor-request-id> </creditor-request-id> <vs-mandate-ref> </vs-mandate-ref> </eom-data> </payload> </eom-msg-rs-to-cred-001> B.6 Error eom-msg-rs-to-cred-001 <?xml version="1.0" encoding="utf-8"?> <eom-msg-rs-to-cred-001 EPC e-operating Model Detailed Specification v1.2 Approved.doc Page April 2013

114 xmlns=" xmlns:xsi=" <header version="1.1"> <date> t15:00:04z</date> <service>mandate</service> <operation>proposal</operation> </header> <payload> <status>100</status> <error-details> <description>internal server error</description> <hint>try again later</hint> <src-message> <eom-msg-cred-to-rs-001> <header version="1.1"> <date> t15:00:01z</date> <service>mandate</service> <operation>proposal</operation> </header> <payload> <eom-data> <vs-address type="bic">bbarpptlxxx</vs-address> <creditor-id>pt </creditor-id> <creditor-request-id> </creditor-request-id> <creditor-return-url> 98fc03334</creditor-return-url> </eom-data> <message> <e-mandate>...</e-mandate> </message> </payload> </eom-msg-cred-to-rs-001> </src-message> </error-details> </payload> </eom-msg-rs-to-cred-001> B.7 eom-msg-cred-to-rs-002 for retrieval of an e-mandate <?xml version="1.0" encoding="utf-8"?> <eom-msg-cred-to-rs-002 xmlns=" xmlns:xsi=" <header version="1.1"> <date> t15:00:05z</date> <service>mandate</service> <operation>retrieval</operation> </header> <payload> <eom-data> <creditor-id>pt </creditor-id> <creditor-request-id> </creditor-request-id> </eom-data> </payload> </eom-msg-cred-to-rs-002> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page April 2013

115 B.8 eom-msg-rs-to-vs-002 for retrieval of an e-mandate <?xml version="1.0" encoding="utf-8"?> <eom-msg-rs-to-vs-002 xmlns=" xmlns:xsi=" <header version="1.1"> <date> t15:00:06z</date> <service>mandate</service> <operation>retrieval</operation> </header> <payload> <eom-data> <creditor-id>pt </creditor-id> <creditor-request-id> </creditor-request-id> </eom-data> </payload> </eom-msg-rs-to-vs-002> B.9 eom-msg-vs-to-rs-002 <?xml version="1.0" encoding="utf-8"?> <eom-msg-vs-to-rs-002 xmlns=" xmlns:xsi=" <header version="1.1"> <date> t15:00:07z</date> <service>mandate</service> <operation>retrieval</operation> </header> <payload> <status>0</status> <eom-data> <creditor-id>pt </creditor-id> <creditor-request-id> </creditor-request-id> <signed-message> <Signature xmlns=" <SignedInfo> <CanonicalizationMethod Algorithm=" <SignatureMethod Algorithm=" <Reference URI="#message"> <DigestMethod Algorithm=" <DigestValue>esrCEau3mPR+QWwyxzZ1uy5u4E1M6wKmKMg5PDgC71Q=</DigestValue> </Reference> <Reference URI="#keyInfo"> <DigestMethod Algorithm=" <DigestValue>o0aZTxQK84IZ2NH7VPUlQyJhl2Sp1YHiMAhHajsIeJQ=</DigestValue> </Reference> </SignedInfo> <SignatureValue>YnJ+XmdVoVxCfgd5LuoryUdTgEVd6CXYkAI0jAbpvzn/GU8OLPzdqK2vdaS/EEkKuPoSwGoP fbjv NpIi4hY45/Nqj/ejkAI+qMYYOhRRnmdtHpqkSH4EVHMwLQhZFTwvN0MdzY8CBbO0q7dfs+p5Cezv OS/5qQlpAat4I4w7td4=</SignatureValue> <KeyInfo Id="keyInfo"> <X509Data> <X509Certificate>MIIGVjCCBT6gAwIBAgIIVQL9SnN9J2MwDQYJKoZIhvcNAQEFBQAwZDELMAkGA1UEBhMCUFQ xejaq BgNVBAoMCVNhbXBsZSBDQTEeMBwGA1UECwwVZS1PcGVyYXRpbmcgTW9kZWwgUEtJMSEwHwYDVQQD DBhlLU9wZXJhdGluZyBNb2RlbCBDQSAwMDEwHhcNMDgwODI2MTA1MDM1WhcNMTExMDI1MTA1MDM1 WjBcMQswCQYDVQQGEwJQVDESMBAGA1UECgwJRGVtbyBCYW5rMRMwEQYDVQQLDAplLU1hbmRhdGVz MSQwIgYDVQQDDBtlLU9wZXJhdGluZyBNb2RlbCBEZW1vIEJhbmswgZ8wDQYJKoZIhvcNAQEBBQAD gy0amigjaogbajfsq4ugzqscnn+mureigxjgqo0o4pwefky4b5k9eqwn/wx3ycbl6udmz5f/mrzv i3p0dyhsgskzwumnsnaoiluffkbde/g7m7yqowj2qw2iuulq8qilulyip50pnjnllebdf1arm9t1 P5p/ZUJZYeHBtgwIOu8cyubwM01CCwijAgMBAAGjggOWMIIDkjA8BggrBgEFBQcBAQQwMC4wLAYI EPC e-operating Model Detailed Specification v1.2 Approved.doc Page April 2013

116 KwYBBQUHMAGGIGh0dHA6Ly93d3cuc2FtcGxlLWNhLmV1L3B1Yi9vY3NwMB0GA1UdDgQWBBSngNtt b83vodlfvrl3nnlqm/zq6dambgnvhrmbaf8eajaamb8ga1udiwqymbaafhkirwbcnwqsyb9cfc6z UZWFRxWWMIIBvAYDVR0gAQH/BIIBsDCCAawwggGoBgwrBgEEAbA8ZAEBAQMwggGWMIIBkgYIKwYB BQUHAgIwggGEHoIBgABUAGgAZQAgAHUAcwBhAGcAZQAgAG8AZgAgAHQAaABpAHMAIABjAGUAcgB0 AGkAZgBpAGMAYQB0AGUAIABmAG8AcgAgAGUAbABlAGMAdAByAG8AbgBpAGMAIABzAGkAZwBuAGEA dab1ahiazqagahaadqbyahaabwbzaguacwagagkabgagageaywbjag8acgbkageabgbjaguaiab3 AGkAdABoACAAdABoAGkAcwAgAGMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAHAAbwBsAGkAYwB5ACAA ZQBuAHQAaQB0AGwAZQBzACAAdABoAGUAIABzAHUAYgBqAGUAYwB0ACAAYQBzACAAYQAgAGwAZQBn AGkAdABpAG0AYQB0AGUAIABzAGkAZwBuAGUAcgAgAGYAbwByACAAdABoAGUAIABCAGEAbgBrACgA cwapacaaaqbkaguabgb0agkazgbpaguazaagagiaeqagahqaaablacaaqgbjaemakabzackaljcb raydvr0fbigkmighmigeodkgmiyuahr0cdovl3d3dy5zyw1wbguty2euzxuvchvil2nybc9lb20t Y2EtMDAxLmNybKJopGYwZDELMAkGA1UEBhMCUFQxEjAQBgNVBAoMCVNhbXBsZSBDQTEeMBwGA1UE CwwVZS1PcGVyYXRpbmcgTW9kZWwgUEtJMSEwHwYDVQQDDBhlLU9wZXJhdGluZyBNb2RlbCBDQSAw MDEwDgYDVR0PAQH/BAQDAgZAMIGEBgNVHREBAf8EejB4oBwGCysGAQQBgZA+ZAEBoA0MC0JCQVJQ UFRMWFhYoBwGCysGAQQBgZA+ZAEBoA0MC0JCQVJQUFRMMDAxoBwGCysGAQQBgZA+ZAEBoA0MC0JC QVJQUFRMWFhYoBwGCysGAQQBgZA+ZAEBoA0MC0JCQVJQUFRMMDAxMA0GCSqGSIb3DQEBBQUAA4IB AQCTDpFEl7mOW7LqyOQE/HyfXFdKRcZBJeZMulG0bVprOlEFYQSkDGImVqC2DdcW6BvBmMt7cfVL +TmgtdFnv7HPJc9QiwiqKxYsjjEZaU69rLBryaAxaTO1tlSmhXTC5GgT/PxHRPjMpb9Say8N+aIq Iok+/WIWnETMi4LFvwsApnTOEI+yN584UkgsIL3YHVpl5VwFHEMDB93R0TUJCoBaz4TL5W67h3/D ACLYhH8skzZBidF+O2/s27RDr+NqH8FNA7XuKDIJYfnBsXqo9wlbUSeb9qQWriFBkgGobxACz3p8 LbE2pcjoY8LxcQpy0O2A4UwDJL5LCXHj249y3+Ld</X509Certificate> <X509Certificate>MIIDrTCCApWgAwIBAgIIJNoByZ381H0wDQYJKoZIhvcNAQEFBQAwZDELMAkGA1UEBhMCUFQ xejaq BgNVBAoMCVNhbXBsZSBDQTEeMBwGA1UECwwVZS1PcGVyYXRpbmcgTW9kZWwgUEtJMSEwHwYDVQQD DBhlLU9wZXJhdGluZyBNb2RlbCBDQSAwMDEwHhcNMDgwODI2MDkyNjE1WhcNMTgwODI0MDkyNjE1 WjBkMQswCQYDVQQGEwJQVDESMBAGA1UECgwJU2FtcGxlIENBMR4wHAYDVQQLDBVlLU9wZXJhdGlu ZyBNb2RlbCBQS0kxITAfBgNVBAMMGGUtT3BlcmF0aW5nIE1vZGVsIENBIDAwMTCCASIwDQYJKoZI hvcnaqebbqadggepadccaqocggebakfpk2uhtujsesdsaq2m00rsmevebsw74pjluhgde1y1u+yx btlxymohz8sojbyfckefxdvnemkx4po/+o8vkbwhyv/z8e2rpwsdbwklwxfgkggfnhgq82pvgdrn Jm5DFBE2ZuuMqXzFGZgh0nfbXB4oQV7TYsljDvXZBhfJetZonggDn7OSmUVNCwVBvwDzAraYGJBK n+ttszdt8l/hbyyxy1ax7kjecmswv+wqhn2myfyqca+5wvrliqper7pbsyskyk1zqu0lna/ygusk zx3l8ohnycekqoxxkadnbocbzxhd1ndwklpupzacyullevfrkshvrlnn1jcmo6s7z1mcaweaaanj MGEwHQYDVR0OBBYEFHkIRwBCnWqsYb9CFC6ZUZWFRxWWMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0j BBgwFoAUeQhHAEKdaqxhv0IULplRlYVHFZYwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBBQUA A4IBAQCGjFB4VzG7yUqvQhJLDD5JQ05e2RqwkK0vLT3m7SRXr3L+u3F6qdqq3uX1x9CHN+c2Ja61 PlauJ+kNUZHjisR1nSE0LANJOzebgtxOgrGERIi8PPaJDFazDPhcfg2ve/WnXkgaAVNUlXR8dHtB ArV7TApKd0K83BR/MqTxQgyaCC3OFJtrg0paUGq1egVe6dv+K3bxxDUCzRP34b7SIVj76AriKYyh AYD+xTn1WMV4cd8ncOX0Pew6r8p2m1vaFkO4Rj9KKZKQAz+UWKiFCbeeFgSX6SUq1HB77U93hobs wkgffwjcny0l1jffgtrby0k3fne+9potcggwykofs/ue</x509certificate> </X509Data> </KeyInfo> <Object Id="message"> <e-mandate xmlns="urn:swift:xsd:$e-mandate.002">this is the business message...</e-mandate> </Object> </Signature> </signed-message> </eom-data> </payload> </eom-msg-vs-to-rs-002> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page April 2013

117 B.10 Error eom-msg-vs-to-rs-002 <?xml version="1.0" encoding="utf-8"?> <eom-msg-vs-to-rs-002 xmlns=" xmlns:xsi=" <header version="1.1"> <date> t15:00:07z</date> <service>mandate</service> <operation>retrieval</operation> </header> <payload> <status>100</status> <error-details> <description>internal server error</description> <hint>try again later</hint> <src-message> <eom-msg-rs-to-vs-002> <header version="1.1"> <date> t15:00:06z</date> <service>mandate</service> <operation>retrieval</operation> </header> <payload> <eom-data> <creditor-id>pt </creditor-id> <creditor-request-id> </creditor-request-id> </eom-data> </payload> </eom-msg-rs-to-vs-002> </src-message> </error-details> </payload> </eom-msg-vs-to-rs-002> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page April 2013

118 B.11 eom-msg-rs-to-cred-002 <?xml version="1.0" encoding="utf-8"?> <eom-msg-rs-to-cred-002 xmlns=" xmlns:xsi=" <header version="1.1"> <date> t15:00:08z</date> <service>mandate</service> <operation>retrieval</operation> </header> <payload> <status>0</status> <eom-data> <creditor-id>pt </creditor-id> <creditor-request-id> </creditor-request-id> <signed-message> <Signature xmlns=" <SignedInfo> <CanonicalizationMethod Algorithm=" <SignatureMethod Algorithm=" <Reference URI="#message"> <DigestMethod Algorithm=" <DigestValue>esrCEau3mPR+QWwyxzZ1uy5u4E1M6wKmKMg5PDgC71Q=</DigestValue> </Reference> <Reference URI="#keyInfo"> <DigestMethod Algorithm=" <DigestValue>o0aZTxQK84IZ2NH7VPUlQyJhl2Sp1YHiMAhHajsIeJQ=</DigestValue> </Reference> </SignedInfo> <SignatureValue>YnJ+XmdVoVxCfgd5LuoryUdTgEVd6CXYkAI0jAbpvzn/GU8OLPzdqK2vdaS/EEkKuPoSwGoP fbjv NpIi4hY45/Nqj/ejkAI+qMYYOhRRnmdtHpqkSH4EVHMwLQhZFTwvN0MdzY8CBbO0q7dfs+p5Cezv OS/5qQlpAat4I4w7td4=</SignatureValue> <KeyInfo Id="keyInfo"> <X509Data> <X509Certificate>MIIGVjCCBT6gAwIBAgIIVQL9SnN9J2MwDQYJKoZIhvcNAQEFBQAwZDELMAkGA1UEBhMCUFQ xejaq BgNVBAoMCVNhbXBsZSBDQTEeMBwGA1UECwwVZS1PcGVyYXRpbmcgTW9kZWwgUEtJMSEwHwYDVQQD DBhlLU9wZXJhdGluZyBNb2RlbCBDQSAwMDEwHhcNMDgwODI2MTA1MDM1WhcNMTExMDI1MTA1MDM1 WjBcMQswCQYDVQQGEwJQVDESMBAGA1UECgwJRGVtbyBCYW5rMRMwEQYDVQQLDAplLU1hbmRhdGVz MSQwIgYDVQQDDBtlLU9wZXJhdGluZyBNb2RlbCBEZW1vIEJhbmswgZ8wDQYJKoZIhvcNAQEBBQAD gy0amigjaogbajfsq4ugzqscnn+mureigxjgqo0o4pwefky4b5k9eqwn/wx3ycbl6udmz5f/mrzv i3p0dyhsgskzwumnsnaoiluffkbde/g7m7yqowj2qw2iuulq8qilulyip50pnjnllebdf1arm9t1 P5p/ZUJZYeHBtgwIOu8cyubwM01CCwijAgMBAAGjggOWMIIDkjA8BggrBgEFBQcBAQQwMC4wLAYI KwYBBQUHMAGGIGh0dHA6Ly93d3cuc2FtcGxlLWNhLmV1L3B1Yi9vY3NwMB0GA1UdDgQWBBSngNtt b83vodlfvrl3nnlqm/zq6dambgnvhrmbaf8eajaamb8ga1udiwqymbaafhkirwbcnwqsyb9cfc6z UZWFRxWWMIIBvAYDVR0gAQH/BIIBsDCCAawwggGoBgwrBgEEAbA8ZAEBAQMwggGWMIIBkgYIKwYB BQUHAgIwggGEHoIBgABUAGgAZQAgAHUAcwBhAGcAZQAgAG8AZgAgAHQAaABpAHMAIABjAGUAcgB0 AGkAZgBpAGMAYQB0AGUAIABmAG8AcgAgAGUAbABlAGMAdAByAG8AbgBpAGMAIABzAGkAZwBuAGEA dab1ahiazqagahaadqbyahaabwbzaguacwagagkabgagageaywbjag8acgbkageabgbjaguaiab3 AGkAdABoACAAdABoAGkAcwAgAGMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAHAAbwBsAGkAYwB5ACAA ZQBuAHQAaQB0AGwAZQBzACAAdABoAGUAIABzAHUAYgBqAGUAYwB0ACAAYQBzACAAYQAgAGwAZQBn AGkAdABpAG0AYQB0AGUAIABzAGkAZwBuAGUAcgAgAGYAbwByACAAdABoAGUAIABCAGEAbgBrACgA cwapacaaaqbkaguabgb0agkazgbpaguazaagagiaeqagahqaaablacaaqgbjaemakabzackaljcb raydvr0fbigkmighmigeodkgmiyuahr0cdovl3d3dy5zyw1wbguty2euzxuvchvil2nybc9lb20t Y2EtMDAxLmNybKJopGYwZDELMAkGA1UEBhMCUFQxEjAQBgNVBAoMCVNhbXBsZSBDQTEeMBwGA1UE CwwVZS1PcGVyYXRpbmcgTW9kZWwgUEtJMSEwHwYDVQQDDBhlLU9wZXJhdGluZyBNb2RlbCBDQSAw MDEwDgYDVR0PAQH/BAQDAgZAMIGEBgNVHREBAf8EejB4oBwGCysGAQQBgZA+ZAEBoA0MC0JCQVJQ UFRMWFhYoBwGCysGAQQBgZA+ZAEBoA0MC0JCQVJQUFRMMDAxoBwGCysGAQQBgZA+ZAEBoA0MC0JC QVJQUFRMWFhYoBwGCysGAQQBgZA+ZAEBoA0MC0JCQVJQUFRMMDAxMA0GCSqGSIb3DQEBBQUAA4IB AQCTDpFEl7mOW7LqyOQE/HyfXFdKRcZBJeZMulG0bVprOlEFYQSkDGImVqC2DdcW6BvBmMt7cfVL +TmgtdFnv7HPJc9QiwiqKxYsjjEZaU69rLBryaAxaTO1tlSmhXTC5GgT/PxHRPjMpb9Say8N+aIq EPC e-operating Model Detailed Specification v1.2 Approved.doc Page April 2013

119 Iok+/WIWnETMi4LFvwsApnTOEI+yN584UkgsIL3YHVpl5VwFHEMDB93R0TUJCoBaz4TL5W67h3/D ACLYhH8skzZBidF+O2/s27RDr+NqH8FNA7XuKDIJYfnBsXqo9wlbUSeb9qQWriFBkgGobxACz3p8 LbE2pcjoY8LxcQpy0O2A4UwDJL5LCXHj249y3+Ld</X509Certificate> <X509Certificate>MIIDrTCCApWgAwIBAgIIJNoByZ381H0wDQYJKoZIhvcNAQEFBQAwZDELMAkGA1UEBhMCUFQ xejaq BgNVBAoMCVNhbXBsZSBDQTEeMBwGA1UECwwVZS1PcGVyYXRpbmcgTW9kZWwgUEtJMSEwHwYDVQQD DBhlLU9wZXJhdGluZyBNb2RlbCBDQSAwMDEwHhcNMDgwODI2MDkyNjE1WhcNMTgwODI0MDkyNjE1 WjBkMQswCQYDVQQGEwJQVDESMBAGA1UECgwJU2FtcGxlIENBMR4wHAYDVQQLDBVlLU9wZXJhdGlu ZyBNb2RlbCBQS0kxITAfBgNVBAMMGGUtT3BlcmF0aW5nIE1vZGVsIENBIDAwMTCCASIwDQYJKoZI hvcnaqebbqadggepadccaqocggebakfpk2uhtujsesdsaq2m00rsmevebsw74pjluhgde1y1u+yx btlxymohz8sojbyfckefxdvnemkx4po/+o8vkbwhyv/z8e2rpwsdbwklwxfgkggfnhgq82pvgdrn Jm5DFBE2ZuuMqXzFGZgh0nfbXB4oQV7TYsljDvXZBhfJetZonggDn7OSmUVNCwVBvwDzAraYGJBK n+ttszdt8l/hbyyxy1ax7kjecmswv+wqhn2myfyqca+5wvrliqper7pbsyskyk1zqu0lna/ygusk zx3l8ohnycekqoxxkadnbocbzxhd1ndwklpupzacyullevfrkshvrlnn1jcmo6s7z1mcaweaaanj MGEwHQYDVR0OBBYEFHkIRwBCnWqsYb9CFC6ZUZWFRxWWMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0j BBgwFoAUeQhHAEKdaqxhv0IULplRlYVHFZYwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBBQUA A4IBAQCGjFB4VzG7yUqvQhJLDD5JQ05e2RqwkK0vLT3m7SRXr3L+u3F6qdqq3uX1x9CHN+c2Ja61 PlauJ+kNUZHjisR1nSE0LANJOzebgtxOgrGERIi8PPaJDFazDPhcfg2ve/WnXkgaAVNUlXR8dHtB ArV7TApKd0K83BR/MqTxQgyaCC3OFJtrg0paUGq1egVe6dv+K3bxxDUCzRP34b7SIVj76AriKYyh AYD+xTn1WMV4cd8ncOX0Pew6r8p2m1vaFkO4Rj9KKZKQAz+UWKiFCbeeFgSX6SUq1HB77U93hobs wkgffwjcny0l1jffgtrby0k3fne+9potcggwykofs/ue</x509certificate> </X509Data> </KeyInfo> <Object Id="message"> <e-mandate xmlns="urn:swift:xsd:$e-mandate.002">this is the business message...</e-mandate> </Object> </Signature> </signed-message> </eom-data> <extended-data/> </payload> </eom-msg-rs-to-cred-002> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page April 2013

120 B.12 Error eom-msg-rs-to-cred-002 <?xml version="1.0" encoding="utf-8"?> <eom-msg-rs-to-cred-002 xmlns=" xmlns:xsi=" <header version="1.1"> <date> t15:00:08z</date> <service>mandate</service> <operation>retrieval</operation> </header> <payload> <status>100</status> <error-details> <description>internal server error</description> <hint>try again later</hint> <src-message> <eom-msg-cred-to-rs-002> <header version="1.1"> <date> t15:00:05z</date> <service>mandate</service> <operation>retrieval</operation> </header> <payload> <eom-data> <creditor-id>pt </creditor-id> <creditor-request-id> </creditor-request-id> </eom-data> </payload> </eom-msg-cred-to-rs-002> </src-message> </error-details> </payload> </eom-msg-rs-to-cred-002> B.13 eom-msg-cred-to-rs-002 for acknowledgement of an e-mandate <?xml version="1.0" encoding="utf-8"?> <eom-msg-cred-to-rs-002 xmlns=" xmlns:xsi=" <header version="1.1"> <date> t15:00:09z</date> <service>mandate</service> <operation>acknowledge</operation> </header> <payload> <eom-data> <creditor-id>pt </creditor-id> <creditor-request-id> </creditor-request-id> </eom-data> </payload> </eom-msg-cred-to-rs-002> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page April 2013

121 B.14 eom-msg-rs-to-vs-002 for acknowledgement of an e-mandate <?xml version="1.0" encoding="utf-8"?> <eom-msg-rs-to-vs-002 xmlns=" xmlns:xsi=" <header version="1.1"> <date> t15:00:10z</date> <service>mandate</service> <operation>acknowledge</operation> </header> <payload> <eom-data> <creditor-id>pt </creditor-id> <creditor-request-id> </creditor-request-id> </eom-data> </payload> </eom-msg-rs-to-vs-002> EPC e-operating Model Detailed Specification v1.2 Approved.doc Page April 2013

122 ANNEX C RECOMMENDED STRATEGIES FOR BIC RESOLUTIONS C.1 Online resolution On the online resolution, the Routing Service queries the Directory Service for each incoming request. The Routing Service sends the operational BIC and the Directory Service returns the corresponding Validation Service URL. For faster processing and improved service availability, it is recommended that Routing Service providers implement a cache strategy to avoid repeated requests on frequent BICs. The cached results must be assigned a maximum validity of 30 days. After that period, the Routing Service must perform a query to refresh the mapping. This process is illustrated in Figure 29. Figure 29: Online BIC resolution EPC e-operating Model Detailed Specification v1.2 Approved.doc Page April 2013

123 C.2 Offline resolution On the offline resolution, the Directory Service provider publishes the full mapping of Operational BICs to their respective Validation Service URLs along with a serial number and the next update date (30 days as a maximum). Subscribing Routing Services download the mapping file at the announced periodic updating dates and cache it (Figure 30). The resolution can then be performed internally (Figure 31). Figure 30: Caching of full BIC resolution tables Figure 31: Offline BIC resolution As an optimization to this model, the Directory Service provider may publish also an additional mapping file containing the differences from the last full mapping file. EPC e-operating Model Detailed Specification v1.2 Approved.doc Page April 2013