Rulebook

This section lists documents referred to in the Rulebook. The convention used throughout is to provide the reference number only, in square brackets. Use of square brackets throughout is exclusively for this purpose.

The keywords “shall”, “should” and “may” are used as described in [1].

The keywords “comply” and “conform” are used as described in [2].

The following actors will collaboratively provide governance for the main elements involved in the solution for the use of Enhanced PEPPOL eDelivery for transport of ISO 20022-based financial messages:

The specifications for use of the ISO 2022-based financial messages are governed by Bits according to the procedures outlined in [23]. The key principles of this procedure are:

The rulebook and the specifications related to the Enhanced PEPPOL eDelivery network will be governed by a corporation between Bits and Difi in accordance with the procedures outlined in [24]. The key principles of these procedure are:

The Norwegian banks are in the process of implementing ISO 20022-based messages for handling of payments, such as payment instructions from customers or notifications sent to customers. This development implies an introduction of ISO 20022-based massages in the bank-customer interface and a gradual phase-out of the currently established formats. As part of this implementation there have also been a growing recognition for improvements to the communication infrastructures used. It is recognised that any future communication infrastructure used in the bank-customer interface need to build upon infrastructures and standards commonly accepted in the market and provide the technical and legal security required for this type of business transactions.

The PEPPOL eDelivery network, currently used by some 90.000 private and public entities being serviced by more than 50 access points and exchanging more than 35 million business documents in 2016, represents such an infrastructure.

The vision of this initiative is to introduce an enhanced version of the PEPPOL eDelivery network as the common solution for transport of ISO 20022-based financial messages.

The objective of this rulebook is to identify and describe the rules, principles and requirements, for the use of the Enhanced PEPPOL eDelivery for transport of ISO 20022-based financial messages between the banks and their customers in the Norwegian market. To achieve this the rulebook makes extensive use of references to technical specifications providing the detailed normative technical content as illustrated below.

Although this rulebook is aimed at the Norwegian market, it is expected that the technical rules, principles and requirements expressed could be applied also in other markets and application domains. The actual use and content of the ISO 20022-based financial messages will however be constrained to the Norwegian market.

The rules, principles and guidelines identified and described in this document are considered as binding for:

Any party claiming compliance to the rules, principles and requirements identified and described in this document may implement additional features in their solutions provided that these additional features do not violate or contradict the rules, principles and requirements described.

The scope of this rulebook is to identify and describe relevant rules, principles and requirements for the use of the Enhanced PEPPOL eDelivery for transport of ISO 20022-based financial messages between the banks and their customers, including

This does however not prevent all or parts of this document to be relevant also for other use cases, such as interbank communications.

The below figure serves to illustrate the scope of this document.

The business level is focused on the business agreement and use of file-based payment services (e.g. general payments, salary, etc.) between the customer and its bank. The business agreement should state that the parties will use Enhanced PEPPOL eDelivery, their responsibilities for connecting to an accredited PEPPOL Access Point as well as registration of the business documents they may receive in a PEPPOL SMP.

The Application level is focused on the use of ISO 20022-based financial messages, identification of the specifications relevant for the payment process (including what messages to use when, and how to handle errors and exceptions, the syntax to use and what information to place where in the files), identification of the requirements for securing the messages and service limitations (e.g. max. file size, timeouts, etc.) and the requirements for secured transfer of files between the bank, customer and their PEPPOL access points.

The messaging and transport level is focused on the agreements and technical specifications for how to interface and interact with the Enhanced PEPPOL eDelivery network as well as the services and service levels to be observed by the actors involved in this infrastructure.

The following principles are considered as prerequisites for this document:

The payment services used by a debtor or the reconciliation services used by a creditor are typically provided by an ERP solution provider. Either by providing the basic ERP and payment/reconciliation functionality for installation on the debtor/creditor own hardware or by offering this functionality as a cloud service.

In any case the ERP solution provider is in no way involved in the business transactions and has no direct responsibility for the actual business content of the ISO 20022-based messages being exchanged.

It is the responsibility of the debtor/creditor to ensure that the payment/reconciliation services it applies comply to the rules, principles and requirements as stated in this document as well as any applicable legal requirements.

Especially in larger organisations the use of a shared service centre is becoming increasingly common. A shared service centre may handle payments on behalf of several legal entities. A shared service centre will typically operate the actual payment/reconciliation services and as such handle the data on behalf of their clients.

It is the responsibility of the debtor/creditor to ensure that any entity acting on its behalf comply to the rules, principles and requirements as stated in this document as well as any applicable legal requirements.

The banks will also frequently make use of third party service provider to do parts of the processing. Such third-party service provider is in no way involved in the business transactions and has no direct responsibility for the actual business content of the ISO 20022-based messages being exchanged.

It is the responsibility of the bank to ensure that the services it applies comply to the rules, principles and requirements as stated in this document as well as any applicable legal requirements.

Each PEPPOL Participant using the Enhanced PEPPOL eDelivery network need to be registered in a PEPPOL SMP^[1]. The PEPPOL SMP is a service, or a repository, containing information about the identity of the PEPPOL Participant (the PEPPOL Participant ID), the type of financial messages it can receive (receive capabilities) and the PEPPOL AP to which the messages should be delivered.

The actual registration in the SMP will be done by the PEPPOL AP Provider.

As there is a close relationship and dependency in the use of ISO 20022-based financial messages in the different business processes as described in section 5 above, the SMP provider need to ensure that the PEPPOL Participants are registered with a formally issued PEPPOL Participant ID and a correct and consistent set of receive capabilities.

A PEPPOL Participant, i.e. a sender or receiver of ISO 20022-based financial messages, will utilise a PEPPOL AP service to gain access to the Enhanced PEPPOL eDelivery Network. The provider of such services, the PEPPOL AP Provider, can be compared to the mailman in a traditional physical mail system. Analogue to this it follows that the PEPPOL AP Provider does not have any responsibility for the content inside of the envelope being handled. Due to the introduction of end-to-end security in the Enhanced PEPPOL eDelivery network, the PEPPOL AP Provider is not even capable of reading or processing the payload within the envelope.

On the other hand, there is a requirement on the PEPPOL AP Providers participating in the Enhanced PEPPOL eDelivery network to offer services and service levels conformant to the stated requirements in [14]. This include a requirement on the PEPPOL AP provider to maintain an internal register of addresses suitable for routing of received messages and acknowledgements to the correct Debtor/Creditor.

The role of the Business Certificate Publisher [32] is to store and make available qualified certificate upon lookup for a receiver who wishes to receive encrypted documents. This makes it possible to introduce end-to-end security. The service can retrieve qualified certificates when a valid combination of participant identifier and business process identifier are used for the lookup. Business processes are used to separate areas like payments and invoicing.

The Business Certificate Publisher thus fulfils the role as a qualified certificate publisher for secure messaging.

The Business Certificate Publisher can be realized as either a centralised or a distributed component in the enhanced PEPPOL eDelivery network^[4], where PEPPOL Participants will have access to store their public keys used within a business process. In the future, it is expected that the SMP will be used to locate an organization’s published certificate, and thus facilitate a decentralised use.

A key aspect of business level security is to ensure that an individual or legal entity is authorized to execute a given operation, such as debiting an account for a certain amount.

Such verification is typically done through

A feasibility study issued by the Norwegian banks identifies the basic requirements for secure and reliable exchange of financial messages between banks and their customers. Besides the traditional key elements of secure and reliable messaging discussed in the sub-sections below, the reports emphasise the need to establish a qualified certificate provider to facilitate security in an environment where the sender and receiver are more or less unknown for each other. These basic requirements have been further elaborated in [12] which defines the minimum security requirements for data transport in the financial industry. This specification defines requirements related to key security aspects such as:

The document defines requirements to be observed by all actors involved in the process.

Validation is used to ensure that the content of a message is technically correct and complies to its governing specification(s). This is typically done by validating an XML instance document against its governing XML Schema and/or by running a set of schematron rules to validate the actual content.

Before sending an ISO 20022-based financial message, the XML-file need to be prepared and packaged into an appropriate envelope format.

To facilitate routing of the envelope between PEPPOL APs, even after its content is encrypted, there is also a need to carry the basic addressing information and information on the type of data carried in the envelope outside of the actual financial message itself. This is typically done using some form of a header that carries data about the business transaction carried in the envelope.

To facilitate internal routing and correct processing of the business transaction by the receiver, there is also a need to carry some metadata about the customer relationship between the bank and its customer outside of the actual ISO 20022-based financial message.

An audit trail is a chronological record, or set of records, that provide documentary evidence of the sequence of activities that have affected a message. In a process involving several actors and roles, an audit trail can be established by collecting acknowledgements generated at different steps in the process.

In addition to the logging, which primarely is done for operational purposes, the acotrors are required to generate and store secure evidence of the documents exchanged.

The Enhanced PEPPOL eDelivery network is built by combining a set of standardised building blocks, some of which are available as open source software. The process of combining the components is elaborated in [13]. A short description of the different components (building blocks) of the Enhanced eDelivery network is given in the following sub-sections.

By combining the building blocks described above, secure end-to-end messaging is achieved. A short description of the process of combining the components is given below and further elaborated in [13]. The technical details of this process may also be found at [31].

The typical process steps involved are:

The components (building blocks) of the Enhanced eDelivery network are implemented as open source components or made available as part of commercially available software products.

The most significant open source components available to realise the functions needed for a sending or receiving PEPPOL Participant or PEPPOL AP Provider are described in the following sub-sections.

In the role as Debtor/Creditor a business entity will have an agreement with its bank acting in the role as Debtor/Creditor Agent.

The bank agreement will provide governance for the business relationship between the two actors, including provisions for the actual use of the relevant ISO 20022-based messages.

In the role as PEPPOL Participant the business entity, as well as the bank, will have an agreement with a PEPPOL AP Provider. The business entity and the bank may make use of the same or different PEPPOL AP Providers.

This service provision agreement will govern the details related to the services offered by the PEPPOL AP Provider and how the PEPPOL AP service is connected to the internal ICT infrastructure of the PEPPOL Participant. The detailed content of this agreement is left for the parties to define.

The PEPPOL Agreement Framework for Enhanced PEPPOL eDelivery is a multilateral agreement between PEPPOL AP Providers for provision of Enhanced PEPPOL eDelivery services. The purpose of this agreement is secure a minimum set of common services and service levels.

The PEPPOL Agreement Framework for Enhanced PEPPOL eDelivery is built up of the following elements:

As is noted above, it is the PEPPOL Participant identified as the sender or receiver of a message that is ultimately responsible for the complete process. This implies that the legal responsibility is transferred somewhere between the sender and receiver. A term frequently used in legislation is “come to the knowledge of”, which in general terms can be interpreted as “the receiver of some information is bound by that information as soon as it enters its domain of responsibility”. Based on this understanding the European Commission has provided a ruling stating that “an electronic message is received as soon as the last byte is received by the recipient’s access point”.

It follows from this that the PEPPOL Participant has responsibility for all service providers acting on its behalf.

In this use case a business entity is using an internal accounting function/department to process its accounting, including all its payments.

The business entity has a business agreement with its bank for use of ISO 20022-based financial messages for straight through processing. It also has an agreement with a PEPPOL AP provider (AP1) giving access to the Enhanced PEPPOL eDelivery network.

The registrations needed in a PEPPOL SMP and the Business Certificate Publisher to support this use case are:

In this use case a business entity is using an internal accounting function/department to process its accounting, including all its payments. The business entity is not aiming for straight through processing of payments, but employs a two-step approval process where the payment transaction is approved in the internet banking system.

Also in this case, the business entity need to have a business agreement with its bank for use of ISO 20022-based financial messages. The Bank Agreement also need to make it clear that final approval of the payment transaction takes place in the internet banking system.

The business entity will also have an agreement with a PEPPOL AP provider (AP1) giving access to the Enhanced PEPPOL eDelivery network.

The registrations needed in a PEPPOL SMP and the Business Certificate Publisher to support this use case are the same as for the previous use case.

In this use case a business entity is using a Shared Service Centre (SSC) to process its accounting, including all its payments, where the SSC is authorized to make payments on behalf of the Debtor.

The business entity has a Bank Agreement for use of ISO 20022-based financial messages for straight through processing authorising the SSC to debit its account. This implies that the SSC will be identified as an initiating party within the ISO 20022-based financial message.

In this use case, it is either the business entity or the SSC acting on behalf of the business entity who is identified as the PEPPOL Participant. Who is allocated the role as PEPPOL Participant depends on the agreement between the business entity and the bank.

In this use case a business entity is using a Shared Service Centre (SSC) to process its accounting, including all its payments, where the SSC is preparing the payment transactions but they are not authorized to make payments on behalf of the business entity. Instead a two-step approval process where the payment transaction is finally approved in the internet banking system is applied.

Also in this use case the business entity need to have a business agreement with its bank for use of ISO 20022-based financial messages. The Bank Agreement also need to make it clear that final approval of the payment transaction takes place in the internet banking system. As the SSC is preparing the actual ISO 20022-based financial message, the SSC will be identified as an initiating party.

Again, it is either the business entity or the SSC acting on behalf of the business entity who is identified as the PEPPOL Participant. Who is allocated the role as PEPPOL Participant depends on the agreement between the business entity and the bank.