Functional Requirements Document

to Instant Payment Flow Application

Version 3

September 2006

By V.Mischenko

Functional Requirements Document

Instant Payment Flow

Table of Contents
1. INTRODUCTION ........................................................................................................................................2 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 2. IDENTIFICATION ......................................................................................................................................2 PURPOSE AND OBJECTIVES OF THE DOCUMENT .......................................................................................2 SCOPE ......................................................................................................................................................2 FORMALISM .............................................................................................................................................3 DOCUMENT STATUS AND CHANGE RECORD ............................................................................................3 REFERENCES ...........................................................................................................................................3 LIST OF ABBREVIATIONS..........................................................................................................................3 DEFINITIONS ............................................................................................................................................4

IPF SYSTEM OVERVIEW.........................................................................................................................6 2.1 2.2 2.3 2.4 2.5 MODEL DESCRIPTION ..............................................................................................................................6 USERS OVERVIEW ...................................................................................................................................6 OPERATIONAL ENVIRONMENT OVERVIEW ..............................................................................................6 FUNCTIONAL OVERVIEW .........................................................................................................................7 COMPONENTS ..........................................................................................................................................7

3.

FUNCTIONAL REQUIREMENTS............................................................................................................8 3.1 OVERALL SYSTEM REQUIREMENTS .........................................................................................................8 3.1.1 Client Requirements .......................................................................................................................8 3.1.2 Exploiter Requirements ..................................................................................................................8 3.1.3 Facilitator Requirements ................................................................................................................9 3.1.4 MathFunctions Developer Requirements .....................................................................................10 3.1.5 System-Wide Functionalities ........................................................................................................11 3.1.6 System Management Requirements ..............................................................................................13 3.1.7 Operational Requirements............................................................................................................14 3.1.8 Human Engineering Requirements...............................................................................................15 3.1.9 Backup Requirements ...................................................................................................................15 3.2 LICENSE AND PERMITS ..........................................................................................................................16 3.3 STATISTICS ............................................................................................................................................16 3.4 LOGS .....................................................................................................................................................17

4.

NON-FUNCTIONAL REQUIREMENTS ...............................................................................................18 4.1 CAPACITY REQUIREMENTS ....................................................................................................................18 4.2 PERFORMANCE REQUIREMENTS ............................................................................................................18 4.3 RECOVERY REQUIREMENTS ..................................................................................................................18 4.4 SECURITY REQUIREMENTS ....................................................................................................................18 4.5 LEGAL AND REGULATORY REQUIREMENTS ...........................................................................................21 4.6 REQUIREMENTS TO STANDARDS............................................................................................................21 4.7 INTERFACE REQUIREMENTS ..................................................................................................................21 4.7.1 General IPF External Interface Requirements .............................................................................22 4.7.2 Exploiter/Facilitator Interface Requirements...............................................................................22 4.7.3 Client/Facilitator Interface Requirements....................................................................................22 4.7.4 Inter-Facilitator Interface Requirements......................................................................................22 4.7.5 TTP/Meter Interface Requirements ..............................................................................................22 4.7.6 Exploiter/TTP Interface Requirements .........................................................................................22 4.7.7 Client/TTP Interface Requirements ..............................................................................................22 4.7.8 Inter-Facilitator Interface Requirements......................................................................................22 4.7.9 Facilitator /Meter Interface Requirements ...................................................................................22 4.8 TESTING REQUIREMENTS ......................................................................................................................22 4.9 REQUIREMENTS TO DOCUMENTATION ...................................................................................................23

Functional Requirements Document

Instant Payment Flow

1.
1.1

Introduction
Identification

This document is the Functional Requirements Document. This addresses the user and functional requirements required for designing and implementing the Instant Payment Flow (IPF) application which is an essential part of the IPF system. The goal of the IPF system is to provide businesses, namely two parties involved in business transactions creditor and debtor, with automated means to distribute payment charges instantly through a payment period according to a pre-defined function of time or any other parameters as can be required by nature of business, specific circumstances or products. In addressing this goal, the IPF system will: (1) insure that the creditor get paid directly for services or goods he provides to the debtor; (2) ensure absolute clarity about the total amount of money due at the end of the agreed payment period; (3) enable exact cash-flow forecast for every given moment through a payment period; (4) insure continuity of money transfer process unless pre-agreed conditions fail. By achieving this goal the following objectives will be accomplished: direct payment for delivered services or goods; quicker circulation of capital; minimization of the need in companys working capital; pre-agreed and sealed-in-the-function payment flows will guarantee payments on schedule, thus curbing the costs of the companys administration; predictable cash-flow; lower costs of borrowed capital; tremendously simplified, and therefore cheaper, accounting procedures; better debt management; lower volatility of the share quotation.

1.2

Purpose and Objectives of the document

The purpose of defining the IPF Functional Requirements Document is to lay down a bases for writing accurate and complete Technical Requirements for the IPF application, and later an IPF Statement of Work which will be based on these requirements. This document establishes the functional and non-functional (operational, performance, security, etc.) requirements for the IPF application to provide the needed direction for the design and development. As specific releases are developed, applicable and more precise requirements will be defined in the lower level specifications.

1.3

Scope

This document provides the top-level requirements from which the IPF application will be developed. It will be augmented by a separate Data Gathering Process and will be further refined during detailed meetings with potential Clients and IPF facilitators. The requirements identified in this document in the Sections 3 and 4 provide the foundation to develop the software application for the system envisioned in the Request for Patent (Aanvrage om Octrooi) [1], and other TBD documents. The Section 3, Functional requirements is divided into the following major requirement groupings: overall system requirements, license and permits and statistics. Overall system requirements in turn are divided in subsection client requirements, exploiter requirements, facilitator requirements, MathFunctions Developer requirements, system wide functionalities, system management requirements, performance requirements, testing requirements, operational requirements, human engineering requirements, security requirements, standard requirements, legal and regulatory requirements. 2

Functional Requirements Document

Instant Payment Flow

The Section 4 contains the following requirement groupings: performance requirements, security requirements, legal and regulatory requirements, interface requirements, testing requirements. All these requirements reflect what criteria the IPF application must satisfy as well as the conditions a user must satisfy to use the IPF application effectively.

1.4

Formalism

To mark requirements formalism is needed which allows each requirement to be identified in a unique way, so that a unique reference will be possible from the architecture, design and other subsequent documentation (acknowledgment principle). When stating requirements care is being taken to describe only "WHAT" a task is to accomplish, not "HOW" it is going to be accomplished. Furthermore, what is being taken into consideration is that requirements have to be assessable, unique, consistent, and free of hidden design decisions. In the Sections 3 and 4 for simplicity the IPF application is called just IPF.

1.5

Document Status and Change Record

Status: This is the Version 3 of the IPF application Functional Requirements document. Change Record (with respect to the Draft version):
Change 1 2 Initial version Security requirements added according to BS7799 security standard. Number of requirements added, editorial changes, references added, number of definitions changed/added. Author V.Mischenko V.Mischenko Paragraph All 4.4 Date of change Jun.2004 Nov.2004 Reason to change Comments

Extending security requirements.

V.Mischenko

various

Sep.2006

Added new requirements

1.6
[1] [2] [3] [4] [5]

References
Request for Patent (Aanvrage om Octrooi) IPF system Business Analysis. Version TBD. IPF system Risk Analysis. Version TBD. Master Thesis Instant Payment Flows, by Dennis Stam, Erasmus University Rotterdam, 2005 Instant Payment Flow, Banking & Finance , august/September 2006

1.7
IPF API TIP TBD TBW TBC TTP

List of abbreviations
Instant Payment Flow Applications Program Interface Transaction Installment Packets To Be Defined To Be Written To Be Confirmed Trusted Third Party 3

Functional Requirements Document

Instant Payment Flow

1.8

Definitions

Bank Payer: The bank holding the IPF account of Payer. Bank Payee: The bank holding the IPF account of Payee. Clients: Both creditor or debtor who choose to set up their processes of transferring (in case of creditor) or receiving (in case of debtor) money as instant payments by means of IPF system. Exploiter: An organisation which after the development and introduction of IPF will take over the IPF exploitation responsibilities like marketing, sales, technical and user support, provisioning of licenses, technical and legal adaptation to new and/or country specific legislation, all kind of administrative issues, etc. External Parties: All organizations supplying supplementary information which can influence the rate of the payment flow. Facilitator: Authorized companies, e.g. accounting firms, bank specialists or other financial advisors with necessary knowledge of financial flows, legislation and IPF system which will be able to advise their clients on establishing of their payment according to IPF principles, assisting with compiling of contracts and definition of payments flow conditions, supervise instant payment flows of their clients for bookkeeping and administrative purposes or otherwise facilitate instant payments of their clients. Installment: One of a number of successive payments in settlement of a debt. Installment rate: The amount of money paid out per unit time. Instant payment: A payment arranged according to the Instant Payment Flow principle whereby the process of money transfer is continuous and permanent within a payment period, as opposed to the installments principle. IPF MathFunctions Developers: Companies with specific mathematical, risk and statistics knowledge which will develop specific payment functions, parameters and boundary conditions as might be requested by Clients or Facilitators. IPF TTP: A trusted third party organizing the IPF transaction and redirecting all necessary information to the other actors. IPF Users Community: The community of IPF Clients, TTPs, Facilitators and, maybe other users, as well as MathFunctions Developers and the Exploiter. MathFunctions Database: Database with prepared and ready-to-use MathFunctions which can directly be taken in operation by users for arranging instant payments after choosing necessary parameters and boundary conditions. Meter: A trusted measuring device supplying information about goods/services being delivered from Payee to Payer. Momentary price: 4

Functional Requirements Document

Instant Payment Flow

A price of goods/services delivered by Payee to Payer at a particular moment of time during trade transaction. Payee: Person or organization supplying goods/services to Payer (or maybe other third party) and therefore having right to receive agreed amount of money per delivery from Payer. Payer: Person or organization receiving goods/services from Payee (or maybe other third party) and therefore is obliged to pay agreed amount of money per delivery to Payee. Transaction Installment Packet: An electronic packet representing a money value and containing information on transaction (Payer, Payee, Bank Payer, Bank Payee, TTP, etc.) necessary to deliver this money value from Payer to Payee.

Functional Requirements Document

Instant Payment Flow

2.
2.1

IPF System Overview

Model Description

The model of the IPF system can be easily understood using the following analogy. Imagine two communicating vessels from your school physics lessons. Imagine water flowing through a tube from the higher vessel to the lower one. Imagine mounting a valve on the tube that regulates the amount of water passing to the lower vessel. The valve can be constructed so that it automatically controls the amount of passing water, depending on, e.g. the air pressure outside, or the wind speed, or any other parameter you want. Eventually, sooner or later, the whole water content of the higher vessel will have travelled to the lower vessel. Now apply this to the phenomenon of payment flow: Every small moment of time a definite amount of cash is written off from the debtors account, and practically simultaneously subscribed to the recipients account. The transfer-rate is defined by mutual predefined agreements about various time-schedules for installments, or any other parameters necessary. By the end of the mutually agreed period of time, or by setting in of other pre-agreed conditions, all cash involved has been transferred from the debtor to the recipient.

2.2

Users Overview
The following (not yet complete) list of users outlines a potential IPF users community:

Companies exploiting pipelines can apply IPF to bill their customers for conveying of oil or gas to them. Data transmission or telephony companies instantly charging for services per time or per transmitted amount of data. Leasing and real estate industries. Municipal economy companies, like electricity, water or sewer systems holders. Government fiscal and budgeting organisations can apply IPF to their specific needs, e.g. pay-per-use of public infrastructure like roads, polders, etc.; or to some policies and methods, e.g. legal minimum reserves for companies. Accounting companies, banking and other financial advisors as a facilitator of Instant Payment Flow: making calculations and forecasts for their clients with one click of the mouse, as various payment flows of a company can be easily combined in one with varying predefined parameters. Banking industry will also take an interest in IPF for performing its credit transactions. The flexibility of the system also makes it applicable for inter-company payments within large multinational concerns. Employers in some branches can use this system to monitor the performance of each employee, and reward him accordingly, by creating a direct link between the status of the employee and the financial reward he receives.

2.3

Operational Environment Overview

The IPF system shall fit in the existing business environment in order to insure continuity of business and payment processes. An environment where the IPF system shall be operational is an existing business environment coupled to conventional banking environment. This means that IPF on one side shall co-exist with conventional payment methods and on the other side shall add previously unknown payment flexibility, convenience and security to various business transactions. IPF shall co-exist with nowadays banking systems and shall interface to them in such a way that it: 1) adds flexibility to payment process, 2) insures payments are on schedule and on-function, 6

Functional Requirements Document 3) secures on-going payments and administration, 4) makes payment administration easier and cheaper, 5) makes them surveyable and convenient for users.

Instant Payment Flow

Legal support of IPF shall be based on the existing legal system, however as soon as IPF is functional and gets more and more users the changes in the business legislation will become unavoidable. Therefore the IPF system shall be build in such a way that it can be adapted to changes in the business legislation.

2.4

Functional Overview

The functional components of the IPF application must be able to respond to many challenges: high number of Clients, high performance, high level of transactions security, high reliability, large volume of transactions, adaptable to reconfiguration, varied functional components, reliable and secure statistics storage, and lightening communication. Each of the components of the IPF application will likely have a large number of Clients and demand a very high performance level. A description of each of these components is provided below.

2.5
TBD:

Components

MathFunction Definition Boundary Conditions Definition Interfaces Operations Communication Legal License and Permits Statistics Security

Functional Requirements Document

Instant Payment Flow

3.
3.1
3.1.1

Functional Requirements
Overall System Requirements
Client Requirements
IPF shall give Clients the opportunity to establish their payments as instant payments. IPF shall give Clients the opportunity to establish their payments as instant payments according to a payment function (MathFunction), its functional parameters and boundary conditions as mutually chosen and agreed by Clients, and depending on external parameters like stock exchange data or any other signals which may be of influence to the momentary price of goods/services. IPF shall provide Clients the opportunity to change during the payment process any or one of the following: MathFunction, its functional parameters, boundary conditions. IPF shall provide Clients the opportunity to stop instant payments and get back to conventional payments; thereby instant payments administration shall easily and accurately interface to other payments administration. IPF shall provide Clients with the opportunity to electronically query authorised instant payments data from their Facilitator and receive them in secure way. IPF shall provide Client with a complete instant payment administration tool which can be accurately coupled to other payment and administrative tools of Client. This administration tool shall administrate the following data regarding instant payments: total payment amount, MathFunction and its functional parameters and boundary conditions, begin time, end time, eventual interruptions, Clients authorisation data, further TBD. IPF shall provide Clients with secure opportunity to award, change and administrate access rights to the IPF Client administration tool for their personnel. IPF shall allow providing Clients with Licenses and Permits. These IPF Client administration tools (or one combined tool) shall be menu-driven to the maximum extent possible. Clients shall not require any special knowledge of the location and function of the IPF system or its (distributed) elements or information transition services being used.

CR.3101.001 CR.3101.002

CR.3101.003

CR.3101.004

CR.3101.005

CR.3101.006

CR.3101.007

CR.3101.008 CR.3101.009

CR.3101.010

CR.3101.011 CR.3101.012 CR.3101.013 CR.3101.014 CR.3101.015 CR.3101.016 CR.3101.017 CR.3101.018 CR.3101.019

3.1.2

Exploiter Requirements
IPF shall be easy to install at Exploiter premises. IPF shall provide opportunity to couple from Exploiter premises to other IPF Users. 8

ER.3102.001 ER.3102.002

Functional Requirements Document

Instant Payment Flow

ER.3102.003 ER.3102.004 ER.3102.005 ER.3102.006

IPF/Exploiter interface shall be menu-driven to the maximum extent possible. IPF shall provide opportunity to remotely support and service Exploiters IPF system. IPF shall provide Exploiter with a simple License and Permits administration tool. This License and Permits administration tool shall be menu-driven to the maximum extent possible. IPF shall provide opportunity to adapt to changing (country) legislation by Exploiter. IPF shall implement applications and infrastructure components that shall allow Exploiter to monitor the effectiveness of Exploiters specific requirements.

ER.3102.007 ER.3102.008

ER.3102.009 ER.3102.010

3.1.3

Facilitator Requirements
IPF shall give Facilitators technical and administrative tools in order to define and establish payments of their Clients as instant payments. IPF shall give Facilitators technical and administrative tools in order to establish payments of their Clients as instant payments according to a payment function (MathFunction), its functional parameters and boundary conditions as chosen by their Clients. IPF shall provide Facilitators with secure opportunity to award, change and administrate access rights to IPF systems of their Clients. All IPF/Facilitator interfaces shall be menu-driven to the maximum possible extent. IPF system at every Facilitator shall be fully triplicated, all hot-running. It shall be made possible to distribute the elements of IPF related to Facilitator between different premises of Facilitator. IPF distributed elements shall operate as a single integrated and cohesive information system. IPF system at every Facilitator shall have a capability to store the following data regarding instant payments: total payment amount, MathFunction and its functional parameters and boundary conditions, begin time of the transaction, end time of the transaction, eventual interruptions, Clients authorisation data, further TBD, for at least 20 years. IPF system at every Facilitator shall have the capability to organize and store all data for aggregation and analysis. IPF system at every Facilitator shall be able to add new storage devices, if required, to serve archiving needs. IPF shall have the capability to search for specific transactions which have been performed or are being performed by Facilitator. IPF shall have the capability to add or remove Clients by Facilitator. IPF shall have the capability to remotely maintain and upgrade the system at Facilitators premises from Exploiters premises. 9

FR.3103.001

FR.3103.002

FR.3103.003

FR.3103.004 FR.3103.005 FR.3103.006

FR.3103.007 FR.3103.008

FR.3103.009

FR.3103.010

FR.3103.011

FR.3103.012 FR.3103.013

Functional Requirements Document

Instant Payment Flow

FR.3103.014

IPF shall provide Facilitators with the capability to generate MathFunctions, their names and define parameters that are both logical and meaningful to the Clients, and compatible with established standards and specifications. IPF shall provide Facilitators with remote access to the MathFunctions Database at the premises of Exploiter. IPF shall provide Facilitators with the capability to search for specific MathFunctions required by Developer in the IPF MathFunctions Database at the premises of Exploiter. IPF shall provide Facilitators with the capability to analyse and modify MathFunctions. For any by Facilitators custom developed MathFunction IPF shall conform to the quality assurance requirements in accordance with Quality Program Provisions, tailored to the IPF Technical Requirements.

FR.3103.015

FR.3103.016

FR.3103.017 FR.3103.018

FR.3103.019 FR.3103.020 FR.3103.021 FR.3103.022 FR.3103.023 FR.3103.024 FR.3103.025 FR.3103.026 FR.3103.027 FR.3103.028 FR.3103.029 FR.3103.030

3.1.4

MathFunctions Developer Requirements

IPF shall establish standards and specifications to enable private MathFunctions Developers to create and market MathFunctions and related services. IPF shall provide Developers with the capability to generate MathFunctions, their names and define parameters that are both logical and meaningful to the Clients, and compatible with established standards and specifications. IPF shall provide authorised Developers with remote access to the MathFunctions Database at the premises of the Exploiter. IPF shall provide authorised Developers with the capability to search for specific MathFunctions required by the Developer in the IPF MathFunctions Database at the premises of the Exploiter. IPF shall provide Developers with the capability to analyse and modify MathFunctions. For any custom developed by Developers MathFunction IPF shall conform to the quality assurance requirements in accordance with Quality Program Provisions, tailored to the IPF Technical Requirements. IPF shall provide Developers with a simple License and Permits administration tool. IPF/Developer interface shall be menu-driven to the maximum extent possible. 10

MD.3104.001

MD.3104.002

MD.3104.003

MD.3104.004

MD.3104.005 MD.3104.006

MD.3104.007 MD.3104.008

Functional Requirements Document

Instant Payment Flow

MD.3104.009

IPF shall provide the functionality to exchange already developed MathFunctions between various Developers. Developers, if they authorised to do so, shall get the possibility to sell/buy developed functions to/from each other as they need and as they find them in the IPF MathFunctions Database at the premises of the Exploiter. The Exploiter shall not be involved in commercial transactions regarding inter-exchange of MathFunctions developed by Developers themselves. (To Be Further Worked Out). IPF shall establish standards and specifications to enable creating MathFunctions and related services. The MathFunctions generated by Developers shall fit in a standard format, so that these MathFunctions can be easily taken over and implemented by Facilitators for the Clients. IPF shall provide a consistent, globally unique naming and addressing scheme for MathFunctions.

MD.3104.010

MD.3104.011

MD.3104.012

MD.3104.013 MD.3104.014 MD.3104.015 MD.3104.016 MD.3104.017 MD.3104.018

3.1.5

System-Wide Functionalities
IPF shall provide a consistent, globally unique naming and addressing scheme for IPF customers and associated devices. Assigning of the globally unique naming and addressing shall be made centrally by the IPF Exploiter. Assigning of the globally unique naming and addressing shall be made automatically following a request of IPF Facilitator or other user to the IPF Exploiter. IPF shall be paperless and web-based. States of accounts, functions and other relevant information shall be accessible to authorised persons/companies in real time and on request. IPF shall be modular in design and shall be designed using modular and reusable programming techniques for ease of maintenance. IPF shall be designed in such a way that it can provide Client and Facilitator interfaces in following languages: English, Spanish, German, French, Italian, Dutch. It shall be made possible to always extend this list of interface languages. IPF applications may be built from a combination of both unique and Commercial Off-TheShelf (COTS) service capabilities. IPF shall facilitate the development of applications; application platforms enabling services shall consist of well-defined Applications Program Interface (API). A standards-based operating system shall be selected for IPF, which will provide formally defined APIs for application program access to IPF platform resources. For any hardware and software purchased in order to facilitate IPF, IPF shall conform to the quality assurance requirements in accordance with Quality Program Provisions tailored to the IPF Technical Requirements. There shall be no unique quality requirements levied for 11

SF.3105.001

SF.3105.002

SF.3105.003

SF.3105.004

SF.3105.005

SF.3105.006

SF.3105.007

SF.3105.008

SF.3105.009

SF.3105.010

Functional Requirements Document

Instant Payment Flow

Commercial Off-The-Shelf (COTS) hardware and software over and above those used by the Exploiter. COTS hardware quality assessments shall be performed through product sampling prior to procurement. SF.3105.011 IPF shall have the capability to ensure that management of data is defined independently of the processes that create or use that data. IPF shall have the capability to format output to support HTML, XML, XBRL and text. The IPF architecture shall be expandable. This requires that the IPF architecture should: include interfaces that will permit easy insertion of additional capabilities as required, (e.g., replacing an Relational Database Management System (RDBMS) with an RDBMS with object oriented extensions, adding new report formats, statistical algorithms, etc.), include interfaces that will permit easy insertion of technology supporting increased capacity demands without significant architecture/design change.

SF.3105.012 SF.3105.013

SF.3105.014

The IPF architecture shall be operationally robust. This requires that the system architecture should: include standard error handling modules permitting the system to degrade "gracefully" in the presence of failures, be functionally redundant when appropriate, ensure that functional allocation to architectural elements does not introduce unacceptable delay or the introduction of human error, e.g. where the human handling results in a delay in IPF availability, support end-to-end system performance analysis.

SF.3105.015 SF.3105.016

IPF shall be designed to permit the easy insertion of new modules and new enhancements. Internal IPF design changes shall be transparent to the IPF Community to the maximum extent possible. Any changes that will not be transparent must be coordinated with the IPF Community before implementation. IPF shall have the capability to complete all requests (e.g., store, retrieve, update, etc.) within 2 seconds. IPF shall have a system of record for legal purposes and shall maintain an audit file in chronological sequence of each transaction and all corresponding corrections made during the transaction by Clients or their Facilitators. It shall be made possible to distribute the elements of IPF between different premises. IPF distributed elements shall operate as a single integrated and cohesive information system. IPF system shall have capability to store the following data regarding instant payments: total payment amount, MathFunction and its functional parameters and boundary conditions, begin time of the transaction, end time of the transaction, eventual interruptions, Clients authorisation data, further TBD, for at least 20 years. IPF system shall have the capability to organize and store all data for aggregation and analysis. 12

SF.3105.017

SF.3105.018

SF.3105.019 SF.3105.020

SF.3105.021

SF.3105.022

Functional Requirements Document

Instant Payment Flow

SF.3105.023 SF.3105.024 SF.3105.025

IPF system shall be able to add new storage devices, if required, to serve archiving needs. IPF shall accommodate usage growth with minimal disruptions. IPF shall be designed to accommodate growth in data rates and volumes for communications and networks. IPF shall have the capability to define and modify Clients access privileges. IPF shall have the capability to remotely maintain and upgrade the system from Exploiters premises. IPF shall use open systems, standard-based architecture to meet functional requirements and to inter-operate with existing banking information systems.

SF.3105.026 SF.3105.027

SF.3105.028

SF.3105.029 SF.3105.030

3.1.6

System Management Requirements

IPF system shall incorporate management capability, which shall include: Configuration Management, Testing and Validation, Fault Detection, Fault Isolation, Fault Recovery, Data Collection, Data Analysis, Data Reporting.

SM.3106.001

SM.3106.002 SM.3106.003 SM.3106.004

IPF system shall provide end-to-end performance monitoring and control. IPF system shall maintain knowledge of current operational status of all IPF elements. IPF system shall be able to add new storage devices, if required, to serve archiving needs (see FR.3103.008), an API that permits IPF to integrate this addition shall be developed and configuration controlled. Necessary configuration control procedures shall be instituted to ensure a complete understanding of IPF system and configuration. IPF system shall provide the capability to manage IPF system operations, administration, archiving, and security functions. IPF system shall establish and maintain accounting information on communications used. IPF system shall establish and maintain configuration information on communications used. IPF system shall support end-to-end system fault isolation of all IPF provided services, including the capability to identify a failing node, element, and/or service, to the level necessary to correct the fault. IPF system shall provide capability to manage IPF fault isolation functions. 13

SM.3106.005

SM.3106.006

SM.3106.007 SM.3106.008 SM.3106.009

SM.3106.010

Functional Requirements Document

Instant Payment Flow

SM.3106.011

IPF system shall provide data quality determination and analysis, error correction, recovery processing, and related quality control procedures and processes. IPF system shall provide for support of coordinated management of elements distributed between different premises. IPF shall implement applications and infrastructure components to facilitate monitoring and measurement. IPF shall implement applications and infrastructure components to permit IPF management to monitor and measure the effectiveness of the IPF system. IPF shall permit inclusion of new or modified requirements during the life of IPF with appropriate established change control procedures. The monitoring shall include the use of the following sensitive application utilities: The monitoring shall include tracking of the following specific transaction: The monitoring shall include review of log-on patterns to determine potentially abnormal system use. The monitoring shall include unsuccessful log-on attempts.

SM.3106.012

SM.3106.013

SM.3106.014

SM.3106.015

SM.3106.016

SM.3106.017

SM.3106.018

SM.3106.019 SM.3106.020 SM.3106.021 SM.3106.022 SM.3106.023

3.1.7

Operational Requirements
IPF shall support operations 24 hours per day, 7 days per week on a continuous basis. The IPF architecture and design shall facilitate operability. This requires that the system architecture should: - where practical, consist of a design where the functional allocation to, and location of, architectural elements is compatible with the human organizational structure, (e.g. data management subsystems are located at Facilitators). - include standard modules supporting maintenance or fault detection and reporting, soft fail over, etc. - support reliability, maintainability and availability commensurate with level of criticality and recoverability. IPF operations shall include services and management functions for the following: configuration, performance, fault, security, accounting, further TBD. IPF operations shall perform coordination functions amongst IPF elements including coordination of transaction functions (e.g., MathFunction performance monitoring and exception resolution) and operational events (e.g., maintenance, testing, upgrades). IPF shall provide a sustaining engineering capability. 14

OR.3107.001 OR.3107.002

OR.3107.003

OR.3107.004

OR.3107.005

Functional Requirements Document

Instant Payment Flow

OR.3107.006

User training shall be provided to authorized personnel to permit full use of the IPF functionality. IPF shall perform its operations in accordance with (TBD) applicable (inter)governmental policies and procedures. Data inputs to the IPF application shall be validated prior to being processed by IPF. Input data shall be validated for out of range values. Input data shall be validated for missing or incomplete data. Input data shall be validated for unauthorised or inconsistent control data. Input data shall be validated for values or volumes that are exceptional to the norm. Invalid input data shall be rejected and security incident shall be initiated. Integrity checks functionality on any data generated by the system shall be provided. Reasonableness check functionality on the volume and values of data output shall be provided. Functionality necessary for scheduling of IPF to certain days, dates or time of day, shall be provided. Functionality necessary for 'roll back' or recovery routines if IPF fails to operate as planned shall be provided.

OR.3107.007

OR.3107.008 OR.3107.009 OR.3107.010 OR.3107.011 OR.3107.012 OR.3107.013 OR.3107.014 OR.3107.015

OR.3107.016

OR.3107.017

OR.3107.018 OR.3107.019

3.1.8

Human Engineering Requirements

IPF shall provide a menu driven screen interface permitting a properly trained user to navigate easily through the different functions of the system. IPF shall provide IPF users with access to information management services at their premises. The IPF user interface shall be tailored to functions, which are authorized for the user.

HE.3108.001

HE.3108.002 HE.3108.003 HE.3108.004 HE.3108.005 HE.3108.006 HE.3108.007 HE.3108.008 HE.3108.009 HE.3108.010

3.1.9

Backup Requirements
Back-up copies of data shall be taken at a TBD frequency to be consistent with the ability to recover cost effectively from any loss or corruption.

BR.3109.001

BR.3109.002 15

Functional Requirements Document BR.3109.003 BR.3109.004 BR.3109.005 BR.3109.006 BR.3109.007 BR.3109.008 BR.3109.009 BR.3109.010

Instant Payment Flow

3.2

License and Permits

IPF shall have the capability to support electronic filing of licenses & permits. IPF shall have the capability to support electronic processing of licenses & permits. IPF shall have the capability to exchange licensing and permitting decisions between the Exploiter and IPF user. IPF shall have the capability to accommodate the decrementing of licenses.

LP.3200.001 LP.3200.002 LP.3200.003

LP.3200.004 LP.3200.005 LP.3200.006 LP.3200.007 LP.3200.008 LP.3200.009 LP.3200.010

3.3

Statistics
IPF shall have capability to store the results of the statistical calculations. IPF shall have capability to permit the user to develop statistical reports based on userfriendly, menu driven computer-based interactive program interface ("wizards"). IPF shall have capability to distribute the results of statistical calculations in response to a specific user request. IPF shall have capability to distribute the results of statistical calculations for standard set of statistical reports. IPF shall have capability to update previous statistical calculations based on new information received by a user. IPF shall have capability to distribute results of updated statistical calculations based on newly arrived information received by a user. IPF shall have capability to update standard statistical calculations on an hourly basis (TBC). IPF shall have capability to develop new standard report formats and modify existing standard report formats using a user-friendly, menu driven computer-based interactive program interface ("wizards").

ST.3300.001 ST.3300.002

ST.3300.003

ST.3300.004

ST.3300.005

ST.3300.006

ST.3300.007 ST.3300.008

ST.3300.009 16

Functional Requirements Document ST.3300.010

Instant Payment Flow

3.4

Logs
The following operations shall be logged by means of automatic (machine generated) logs - TBD -

LG.3400.001

LG.3400.002 LG.3400.003 LG.3400.004 LG.3400.005 LG.3400.006

Logs shall include IPF process start and finish times. Logs shall include IPF application faults, errors and recovery processes. Logs shall include the use of any privileged passwords. Logs shall include the use of any privileged utilities. Logs shall include automatically generated data necessary to asses the IPF application performance. This in accordance with the performance requirements as described elsewhere in this document. The frequency of logs generation shall be TBD, in order to be consistent with the ability to trace appropriate actions of the application. Logs shall include all log-ons and log-outs as well as all attempts (whether successful or not) to log-on. Logs shall have appropriate (TBD) retention period. The log generating software shall prohibit amendment of log details and disabling of the recording of events. The log generating software shall include review of log-on patterns to determine potentially abnormal system use. Files of logged events shall be protected from amendment or deletion. Logging process shall always be enabled except when explicitly disabled by a supervisor role. Controls shall be in place to prevent the logging process from being disabled.

LG.3400.007

LG.3400.008

LG.3400.009 LG.3400.010

LG.3400.011

LG.3400.012 LG.3400.013 LG.3400.014 LG.3400.015

17

Functional Requirements Document

Instant Payment Flow

4.
4.1

Non-functional Requirements
Capacity Requirements

CP.4101.001 CP.4101.002

4.2

Performance Requirements
IPF shall provide performance availability consistent with the functions provided. The operational availability of IPF shall be determined by a TBD formula. The time service as available is measured over a contiguous 10,000 hour interval, except that any loss of availability due to loss of facility services, such as power, shall not be counted. The time service is not available shall include all times service is not available due to corrective maintenance downtime, administrative downtime, logistics supply downtime, and preventive maintenance downtime. IPF shall predict and periodically assess maintainability by measuring the actual MeanTime-to-Restore-Service (MTTRS) and comparing to the required MTTRS. IPF shall have the maximum time-to-restore-service and it shall not exceed twice the required MTTRS in 99,9 percent of failure. Once a user has successfully navigated to the IPF front end user interface, IPF shall be available to address users request 99.99 percent of the time. IPF shall provide a Mean Time to Restore (MTTR) of 0,5 hours. IPF shall provide a level of service where less than 0.001 percent of all Transaction Installment Packets are lost due to whatever errors with data transmission. IPF shall maintain/assure the integrity of all data received, stored, and transmitted. Peak processing TBD

PR.4200.001 PR.4200.002

PR.4200.003

PR.4200.004

PR.4200.005

PR.4200.006 PR.4200.007

PR.4200.008 PR.4200.009

PR.4200.010

4.3

Recovery Requirements

Recovery and restart requirements RR.4300.001 RR.4300.002

4.4

Security Requirements
The IPF development team shall communicate with TBD potential users to assure the security concerns are incorporated and considered during the design for IPF security. 18

SR.4400.001

Functional Requirements Document SR.4400.002 SR.4400.003 IPF shall provide security consistent with the functions provided.

Instant Payment Flow

The appropriate level of protection for IPF will be determined by the level of security required of the data generated and transmitted by IPF and stored in IPF. IPF shall prevent unauthorized users from accessing the system. IPF shall make data available to the authorized users in an expedient and secure environment. IPF shall insure that Client-, Facilitator-, Exploiter-, MathFunction Developer and transaction level data and communication be protected from unauthorized parties. IPF shall provide access monitoring to compile and report security violations and attempted security violations. IPF shall have the thorough capability to a log record of an unauthorized attempt. IPF shall provide physical and remote access control to IPF systems. IPF shall evaluate the following security measures such as encryption and firewalls, which shall provide a model for the IPF design. IPF shall implement controls to ensure the privacy of information, individuals, and corporations are not compromised. IPF shall use audit controls, electronic signatures, data encryption and other TBD methods to assure the authenticity of transaction and other relevant data. IPF database management security services shall include access control (e.g., Discretionary Access Control (DAC), Mandatory Access Control (MAC), content-dependent and contextdependent access control), individual user identification and authentication (I&A), data confidentiality, data integrity (e.g., entity integrity, referential integrity, and label integrity), security audit, object reuse, availability of service and data, and other TBD security services. IPF shall implement controls to ensure the authenticity of data is preserved. IPF shall comply with the (TBW) IPF Security Plan. IPF shall adhere to TBD guidelines for physical, personnel, computer, communications, and internal data security. IPF shall be foreseen of user registration system allowing: - distinguishing different user roles; - authorisation of users; - authentication of users. IPF shall be foreseen with an access control policy functionality allowing access of users in different roles to different functionalities of IPF. At least the following roles shall be introduced for IPF: - supervisor the role providing IPF operators with access to various IPF functionalities necessary to operate the IPF system, and having access to IPF logs; - operator the role which is allowed to daily operate the IPF system, and allowed a read-only access to IPF logs; - system support the role having access to the code of IPF and IPF databases, and being responsible for maintenance of the code and the databases; - Payer user the role having access to Payers payment data, Payers IPF bank account data, externally supplied data and meter data; 19

SR.4400.004 SR.4400.005

SR.4400.006

SR.4400.007

SR.4400.008 SR.4400.009 SR.4400.010

SR.4400.011

SR.4400.012

SR.4400.013

SR.4400.014 SR.4400.015 SR.4400.016

SR.4400.017

SR.4400.018

Functional Requirements Document -

Instant Payment Flow

Payee user the role having access to Payee payment data, Payees IPF bank account data, externally supplied data and meter data; TTP (Trusted Third Party) user the role having access to Payee and Payer payment data as well as meter data, to payment functions data and to externally supplied data;

SR.4400.019 SR.4400.020

Only registered users shall be allowed to log-in to the IPF application. Registered users shall be allowed to log-on only to those IPF functions which they are authorised to access and use. Registration of users in their respective roles shall be valid only for a limited period of time, whereafter their authorisation shall be re-confirmed and prolonged. Additional access controls shall be considered for log-on to IPF (such as biometric devices or physical tokens). The logon processes shall display only the minimum amount of information to assist users. The logon processes shall prohibit the display of help screens. The logon processes shall minimise the opportunities for unauthorised connections to IPF. The logon processes shall prohibit the display of the IPF system or the application details until the process has been successfully completed. The logon process shall deny access if either the username or password is invalid without identifying the specific erroneous element. The logon process shall allow only a fixed number of logon attempts before disabling the terminal. If access is denied following repeated unsuccessful logon attempts, this shall be treated by the application as a security incident and handled accordingly. The logoff procedure shall clear any screen displays prior to terminating the application. IPF shall disallow simultaneous logon by the same user. Passwords to log-on to IPF (and additional access control devices) shall have at least the length of TBD characters. The password management system shall require the enforcement of a minimum password length. The password management system shall require the use of quality (i.e. difficult to guess) passwords. The password management system shall require the enforcement of a password change after a TBD period. The password management system shall include non-display of the password when being entered. The password management system shall require the storage of passwords in encrypted form. For all security incidents a duress alarm functionality shall be implemented, which immediately informs the supervisor role of these incidents. IPF shall treat the following events as security incidents: 20

SR.4400.021

SR.4400.022

SR.4400.023 SR.4400.024 SR.4400.025 SR.4400.026

SR.4400.027

SR.4400.028

SR.4400.029

SR.4400.030 SR.4400.031 SR.4400.032

SR.4400.033

SR.4400.034

SR.4400.035

SR.4400.036 SR.4400.037

SR.4400.038

Functional Requirements Document - unsuccessful log-on to IPF; - intrusion detection; - malfunctioning of encryption functionality; IPF shall handle the security incidents as follows: TBW

Instant Payment Flow

SR.4400.039

SR.4400.040

4.5

Legal and Regulatory Requirements

IPF shall provide flexibility to easily modify the system to handle changes in trade laws, regulations, license & permit requirements. IPF shall have the capability to search and analyse payment transactions for enforcement purposes.

LR.4500.001

LR.4500.002

LR.4500.003 LR.4500.004 LR.4500.005 LR.4500.006 LR.4500.007 LR.4500.008 LR.4500.009 LR.4500.010

4.6

Requirements to Standards
IPF shall maximize the effective use of applicable international, national, commercial, banking standards for development and operations. IPF shall adhere to TBD standards for Open System hardware and software and be compliant to an Open System Architecture in the part regarding development of MathFunctions and user interfaces. IPF shall use a TBD standard communication protocol. The communications and networks utilized or provided by IPF shall make maximum practicable use of standards for data transportation defined by TBD. IPF shall maximize effective use of TBD systems management standards.

SD.4600.001

SD.4600.002

SD.4600.003 SD.4600.004

SD.4600.005 SD.4600.006 SD.4600.007 SD.4600.008 SD.4600.009 SD.4600.010

4.7

Interface Requirements

21

Functional Requirements Document

Instant Payment Flow

4.7.1

General IPF External Interface Requirements

4.7.2

Exploiter/Facilitator Interface Requirements

4.7.3

Client/Facilitator Interface Requirements

4.7.4

Inter-Facilitator Interface Requirements

4.7.5

TTP/Meter Interface Requirements

4.7.6

Exploiter/TTP Interface Requirements

4.7.7

Client/TTP Interface Requirements

4.7.8

Inter-Facilitator Interface Requirements

4.7.9

Facilitator /Meter Interface Requirements

4.8

Testing Requirements
Standard procedures shall be established to test compliance and conformance of equipment to be used to facilitate IPF to IPF Standards and to certify interoperability and portability of information systems coupled to IPF systems. All corrections to address IPF discrepancies shall be validated through formal regression test before insertion into the operational IPF systems. IPF shall support the revalidation of performance capabilities whenever an element(s) upgrade/enhancement is made to IPF, which may cause a change in performance. All new IPF functionality shall be validated through a formal extensive testing before insertion into the operational IPF systems. IPF shall support operations and testing concurrently. IPF shall provide tools and metrics to support testing, system performance monitoring, fault 22

TR.4800.001

TR.4800.002

TR.4800.003

TR.4800.004

TR.4800.005 TR.4800.006

Functional Requirements Document isolation, verification and validation of the end-to-end system. TR.4800.007 TR.4800.008 TR.4800.009 TR.4800.010

Instant Payment Flow

4.9

Requirements to documentation

TR.4900.001 TR.4900.002 TR.4900.003 TR.4900.004 TR.4900.005

23