Sociologi. Service. Företagsorganisation och företagsledning. Administration. Transport Administration

1.1 This document provides guidance for the development, implementation, maintenance and continual improvement of an innovation management system. It is applicable to:

a) organizations seeking sustained success by developing and demonstrating their ability to effectively lead and organize innovation activities and achieve the intended outcomes;

b) users and other interested parties, e.g. customers, suppliers, partners, funding organizations, investors, universities, and public authorities, seeking confidence in innovation capability.

c) organizations and interested parties seeking to improve communication through a common understanding of the key elements constituting an innovation management system;

d) providers of training, assessment or advice in innovation management and innovation management systems;

e) innovation policy makers, aiming for higher effectiveness of support programs targeting innovation capability and competitiveness.

1.2 All the guidance within this document is generic and intended to be applicable to:

a) all types of organizations, regardless of type, sector, maturity or size. The focus is on established organizations rather than on temporary or start-up organizations. The latter organizations can obtain guidance from certain clauses of this document;

b) all types of innovations, e.g. product, service, process, model, method innovations, from incremental to radical innovations etc.;

c) all types of innovation approaches, e.g. internal, collaborative, user, market, technology and design driven innovation etc.

This document is not for certification purposes. It does not prescribe any requirement, specific tool or method.

This International Standard provides a framework that organisations can follow, and that can be used as the structure for market or sector specific schemes.

A scheme developed following these guidelines can be validated by accreditation organisations and should produce verifiable results.

One side benefit of the standard is to have worldwide comparable certifications, as long as they are based on this schema/guidelines.

The Standard used in the scope (for the certification) is referred to as "THE REFERENCED STANDARD" throughout this document.

This document specifies complaints handling principles related to domestic and international postal services. It applies to both national and cross border services. Attention is given to how to handle complaints in multiple operator situations. The standard also gives guidance for compensation and redress procedures.

This document can be applied to all types of postal service, both universal service and non-universal service, and by all types of postal organizations. It defines various types of complaints and establishes a methodology for handling complaints in order to improve the service given to postal users. It also gives guidance for complaints handling processes to be set up by postal service providers in order to improve quality of service.

This document provides guidelines beyond the requirements given in ISO 10002 and EN ISO 9001 in order to consider both the effectiveness and efficiency of a complaint handling process, and consequently the potential for improvement of the performance of an organization. When compared to EN ISO 9001, the objectives of customer satisfaction and product quality are extended to include the satisfaction of interested parties and the performance of the organization.

This document is applicable to the processes of the organization and consequently the quality management principles on which it is based can be deployed throughout the organization. The focus of this document is the achievement of ongoing improvement, measured through the satisfaction of customers and other interested parties.

It is important to note that the number of complaints received might not be related to the level of service given. A large number of complaints may on the contrary reflect the effectiveness of the postal operator's complaint handling process.

This document consists of guidance and recommendations and is neither intended for certification, regulatory or contractual use, nor as a guide to the implementation of EN ISO 9001.

The relationship with the second edition of this document is explained in Annex I.

This document specifies the minimum elements of an unambiguous legal entity identifier (LEI) scheme to identify the legal entities relevant to any financial transaction.

It is applicable to "legal entities", which include, but are not limited to, unique parties that are legally or financially responsible for the performance of financial transactions or have the legal right in their jurisdiction to enter independently into legal contracts, regardless of whether they are incorporated or constituted in some other way (e.g. trust, partnership, contractual). It includes governmental organizations, supranationals and individuals when acting in a business capacity1), but excludes natural persons.

The LEI is designed for automated processing. It can also be conveniently used in other media interchange when appropriate (e.g. paper document exchange).

NOTE Examples of eligible legal entities include, without limitation:

— all financial intermediaries;

— banks and finance companies;

— all entities that issue equity, debt or other securities for other capital structures;

— all entities listed on an exchange;

— all entities that trade stock or debt, investment vehicles, including mutual funds, pension funds and alternative investment vehicles constituted as corporate entities or collective investment agreements (including umbrella funds as well as funds under an umbrella structure, hedge funds, private equity funds, etc.);

— all entities under the purview of a financial regulator and their affiliates, subsidiaries and holding companies;

— sole traders (as an example of individuals acting in a business capacity);

— counterparties to financial transactions.

This document defines requirements for short-range communication for the purposes of compliance

checking in autonomous electronic fee-collecting systems. Compliance checking communication (CCC)

takes place between a road vehicle's on-board equipment (OBE) and an outside interrogator (road-side

mounted equipment, mobile device or hand-held unit), and serves to establish whether the data that are

delivered by the OBE correctly reflect the road usage of the corresponding vehicle according to the rules

of the pertinent toll regime.

The operator of the compliance checking interrogator is assumed to be part of the toll charging role as

defined in ISO 17573. The CCC permits identification of the OBE, vehicle and contract, and verification

of whether the driver has fulfilled his obligations and the checking status and performance of the OBE.

The CCC reads, but does not write, OBE data.

This document is applicable to OBE in an autonomous mode of operation; it is not applicable to

compliance checking in dedicated short-range communication (DSRC)-based charging systems.

It defines data syntax and semantics, but does not define a communication sequence. All the attributes

defined herein are required in any OBE claimed to be compliant with this document, even if some values

are set to “not defined” in cases where certain functionality is not present in an OBE. The interrogator is

free to choose which attributes are read, as well as the sequence in which they are read. In order to

achieve compatibility with existing systems, the communication makes use of the attributes defined in

ISO 14906 wherever useful.

The CCC is suitable for a range of short-range communication media. Specific definitions are given for

the CEN-DSRC as specified in EN 15509, as well as for the use of ISO CALM IR, the Italian DSRC as

specified in ETSI ES 200 674-1 and ARIB DSRC as alternatives to the CEN-DSRC. The attributes and

functions defined are for compliance checking by means of the DSRC communication services provided

by DSRC layer 7, with the CCC attributes and functions made available to the CCC applications at the

road-side equipment (RSE) and OBE. The attributes and functions are defined on the level of application

data units (ADU).

This document defines requirements for short-range communication for the purposes of compliance

checking in autonomous electronic fee-collecting systems. Compliance checking communication (CCC)

takes place between a road vehicle's on-board equipment (OBE) and an outside interrogator (road-side

mounted equipment, mobile device or hand-held unit), and serves to establish whether the data that are

delivered by the OBE correctly reflect the road usage of the corresponding vehicle according to the rules

of the pertinent toll regime.

The operator of the compliance checking interrogator is assumed to be part of the toll charging role as

defined in ISO 17573. The CCC permits identification of the OBE, vehicle and contract, and verification

of whether the driver has fulfilled his obligations and the checking status and performance of the OBE.

The CCC reads, but does not write, OBE data.

This document is applicable to OBE in an autonomous mode of operation; it is not applicable to

compliance checking in dedicated short-range communication (DSRC)-based charging systems.

It defines data syntax and semantics, but does not define a communication sequence. All the attributes

defined herein are required in any OBE claimed to be compliant with this document, even if some values

are set to “not defined” in cases where certain functionality is not present in an OBE. The interrogator is

free to choose which attributes are read, as well as the sequence in which they are read. In order to

achieve compatibility with existing systems, the communication makes use of the attributes defined in

ISO 14906 wherever useful.

The CCC is suitable for a range of short-range communication media. Specific definitions are given for

the CEN-DSRC as specified in EN 15509, as well as for the use of ISO CALM IR, the Italian DSRC as

specified in ETSI ES 200 674-1 and ARIB DSRC as alternatives to the CEN-DSRC. The attributes and

functions defined are for compliance checking by means of the DSRC communication services provided

by DSRC layer 7, with the CCC attributes and functions made available to the CCC applications at the

road-side equipment (RSE) and OBE. The attributes and functions are defined on the level of application

data units (ADU).

The development of a Financial Instrument Global Identifier originated out of the recognition that chaos theory has

nothing on the complexity generated everyday by the millions-perhaps billions-of security transactions that cross trading

floors, clearinghouses, and exchanges all over the world. Almost every aspect of securities management is based on

closed systems that use proprietary identifiers that are privately owned and licensed. Closing each deal is as much an

exercise in translation as it is in transaction processing, as traders, investors, and brokers wrestle with multiple proprietary

formats to determine what a security is, who owns it, how much it is worth, and when the deal should be closed. It

introduces a tremendous amount of friction into the trade lifecycle and creates opaqueness where clarity is sought. In

addition, the use of proprietary identifiers adds significant cost and overhead when users wish to integrate data from

disparate sources or migrate to a different market data system.

The evolution of advanced symbologies has helped the securities industry grow, but the limitations and costs imposed by

the closed systems have become more apparent as companies and institutions continue to integrate operations on a global

scale. Proprietary symbology now stands as one of the most significant barriers to increased efficiency and innovation in

an industry that sorely needs it. Moreover, the lack of common identifiers is a key roadblock to achieving the holy grail

of straight-through processing (STP).

Points of Note:

Licensing fees require firms to pay for each symbol system they use. International firms bear an especially heavy burden,

because they often have to license several symbologies in order to manage trading operations in several countries.

Restrictions imposed by proprietary symbologies prevent companies from easily mapping one set of codes to another.

This hinders integration of market data from diverse sources as well as efforts to automate trade and settlement activities.

Market data consumers who adopt proprietary symbols for use in their own systems must not only pay licensing fees, but

such symbols also lead to significant future costs associated with efforts to connect to emerging trading systems.

Proprietary trading environments may have worked well for years; but they are a byproduct of a time when data systems

operated largely as islands that did not have to interoperate with other systems.

Current trends dictate a different approach. Markets, customers, and governments are demanding greater connectivity,

transparency, and efficiency. What’s more, the openness of Internet-based systems has profoundly altered the way

businesses-and individuals-collect, manage, and share information. Thus, in addition to new regulations that demand

clarity and accountability, the move to open symbology is being driven by growing investor and institutional demands.

Adopting an open system of shared symbology establishes the foundation for a tremendous leap forward in the efficient

trade and settlement of securities as well as data management and reporting of financial instruments more generally.

Such a system will allow firms and technology service providers to shift resources from laborious, inefficient processes to

new investments in tools and products that will better serve clients.

An open system answers the call for greater transparency. Eliminating the need to remove proprietary IDs and re-map

financial instruments will greatly simplify the steps needed to migrate between market data platforms and trading

systems. Availability of a central symbology reference will facilitate mapping between users’ internal systems and create

opportunities for integration and automation of the global enterprise. This is to say that this standard represents a novel

solution in the market that is not currently covered by other identifiers currently in circulation.

This specification lays out the details of the Financial Instrument Global Identifier across two dimensions:

1. The specification of the structure of the Global Identifier itself—what is/is not valid as a Global Identifier and how a

Global Identifier is constructed and validated.

2. An ontological model specifying the relationship between the Global Identifier and other closely related information.

This International Standard has been created with the clear understanding that a published interface for creating identifiers

and linking together relevant parties, e.g., Certified Providers or the Registration Authority, through the use of technology

is a critical part of the operationalization of this standard. While high level descriptions of the various types of

organizations that need to be involved as well as high level descriptions of the interactions between such organizations

has been included in this International Standard, they are included on the understanding that there will need to be a

subsequent standard produced that details the necessary technical infrastructures and service level agreements for all

participating organizations. To be clear, the technical specification of those services and service level agreements is out of

scope for this document.

Global Identifier concepts are documented using two forms of definition:

1. A structured ontology specification of the concept, and its relationships to others, represented using the Web

Ontology Language (OWL), in the form of (a) RDF/XML serialized OWL, (b) ODM (Ontology Definition

Metamodel)-compliant ODM XMI, and (c) ODM-compliant UML XMI.

2. Natural language definitions which represent the concepts in natural language using the vocabulary of the finance

industry.

Two controlled vocabularies in rdf format, one specifying the list of possible values for security types, one specifying the

list of possible values for pricing sources. These lists are subject to growth over time as new security types are either

invented or incorporated into FIGI and as new pricing sources are taken into account.

This International Standard covers both the content of the models, and the underlying architecture employed for

producing and presenting the model.

This model is developed from a previously existing infrastructure that is currently active and had issued in excess of 150

million FIGI-compliant identifiers to date. The currently issued identifiers are freely available on a web site and through

data files and are delivered upon request in bulk on a daily basis to interested parties. The purpose of this International

Standard, however is to specify the structure of the Identifier itself and its relationship to key information elements rather

than to specify the technology and related interfaces used to generate, access, and manage the identifiers.