ISO/TC 68 - Financial services

This document provides a list of recommended ISO cryptographic algorithms for use within applicable ISO TC 68, Financial services, standards. It also provides strategic guidance on key lengths and associated parameters and usage dates. This document focuses on core algorithms, key lengths and frequently used mechanisms. The included algorithms are considered to be fit for purpose for financial service use. For additional algorithms, see the body of standards produced by ISO/IEC JTC 1 SC 27, Information security, cybersecurity and privacy protection. For standards on key management, see ISO 11568. The categories of algorithms covered are: a) block ciphers and modes of operation; b) stream ciphers; c) message authentication codes (MACs); d) authenticated encryption algorithms; e) format preserving encryption; f) hash functions; g) asymmetric algorithms: 1) digital signature schemes giving message recovery; 2) digital signatures with appendix; 3) asymmetric ciphers. h) authentication mechanisms; i) key derivation, establishment and agreement mechanisms; j) key transport mechanisms: 1) key wrapping. This document does not define any cryptographic algorithms. However, the standards to which this document refers contain necessary implementation information as well as more detailed guidance regarding choice of security parameters, security analysis and other implementation considerations.

This document specifies cryptographic methods for: — PIN generation; — reference PIN change; — transaction PIN verification. These PIN management functions can be implemented using: — encryption using an approved algorithm (see REF Table_tab_1 \r \h Table 1 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000C0000005400610062006C0065005F007400610062005F0031000000 ); — CMAC using an approved block cipher (see REF Table_tab_1 \r \h Table 1 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000C0000005400610062006C0065005F007400610062005F0031000000 ); — HMAC using an approved hash algorithm (see REF Table_tab_1 \r \h Table 1 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000C0000005400610062006C0065005F007400610062005F0031000000 ). Refer to ISO 9564-1 for basic principles & requirements regarding PIN establishment.

This document provides an overview of regulatory, business and best practice risk mitigation specifications that apply to the implementation, operation and governance of natural person identifier (NPI) policies, procedures and mechanisms necessary to support the lifecycle of all NPIs. The purpose of this document is to provide the basis for the development of one or more international standards related to the safe creation, use and management of NPIs with maximum global interoperability. For the structure of the NPI, see ISO 24366. For reference, ISO 24366 specifies a machine-readable, unambiguous NPI and the relevant reference data to uniquely identify the natural person relevant to any financial transaction rather than the personal identifying information.

This document gives requirements and guidance on security controls and implementation for third-party payment service providers (TPPSPs). This document deals with the overall security controls of TPPSPs from developing and testing to installing, operating and auditing the system. These security controls consist of: — security governance controls; — cross-functional controls; — function-specific controls.

This document specifies approved algorithms for the encipherment of personal identification numbers (PINs).

This document defines the data elements included in the registry record and used to establish the 1:1 relationship between a digital token and the identifier assigned according to the method in ISO 24165-1.

This document defines the assignment and generation of a random, unique, fixed-length identifier for digital tokens in response to a request for registration that conforms to specified application guidelines (see also ISO 24165-2).

This document is concerned with the representation of the ISO 20022 e-Repository contents in RDF and OWL by developing a case study around the ISO 20022 auth.016 sample message (hereafter simply referred to as “auth.016”). This includes: a) transformation of the sample message into an RDF instance graph; b) demonstrating a set of SPARQL rules that transform the auth.016 message into a FIX TradeCaptureReport(35=AE) message (hereafter simply referred to as “FIX AE”); c) expressing the metamodel, business components and message components exactly with a custom RDF vocabulary; d) representing those schemas as OWL schemas using OWL vocabulary when possible and annotation properties otherwise; e) creating instance graphs for the auth.016 sample messaging using the vocabulary of the business components and message components. This document also discusses the choices that arise in structuring RDF documents equivalent to documents in XML, and FIX Tag-Value format balancing considerations such as preserving the order of parts of the message versus creating graphs that are suitable for RDFS and OWL inference.

This document provides guidelines for a security framework to address the implementation of security mechanisms in technical infrastructures designed for the provision of third-party payment (TPP) services in order to achieve the security objectives defined in ISO 23195. The security framework is intended to protect critical systems and objects within the TPP system environment, either under the direct control of the third-party payment service provider (TPPSP) or by another entity (e.g. a bank). This document is applicable to the provision of any TPP service, including: — the TPP logical structural model; — the definition of the security framework; — the design principles, responsibilities and functional recommendations to support the security mechanism; — guidelines for applying the security framework defined in this document.

This document specifies rules for an international method for building financial instrument short names (FISNs) for any kind of financial or referential instrument within a defined structure. Financial or referential instruments include, but are not limited to, those described by ISO 10962. This document is applicable to any application in the trading and administration of financial or referential instruments in the financial services. The FISN code takes into account the need for human-readability as well as interoperability with existing standards and systems.

This document specifies the use of the legal entity identifier (LEI) code, represented in ISO 17442-1, in authentic chained data container (ACDC) credentials.

This document specifies the security characteristics for secure cryptographic devices (SCDs) based on the cryptographic processes defined in the ISO 9564 series, ISO 16609 and ISO 11568. This document states the security characteristics concerning both the operational characteristics of SCDs and the management of such devices throughout all stages of their life cycle. This document does not address issues arising from the denial of service of an SCD. This document does not address software services that use multi-party computation (MPC) to achieve some security objectives and, relying on these, offer cryptographic services. NOTE These are sometimes called “soft” or software hardware security modules (HSMs) in common language, which is misleading and does not correspond to the definition of HSM in this document.

This document provides an overview, risk assessment, minimum security requirements and extended security guidelines for code-scanning payment in which the payer uses a mobile device to operate the payment transaction. This document is applicable to cases where the payment code is used to initiate a mobile payment and presented by either the payer or the payee. The following is excluded from the scope of this document: — details of payer and payee onboarding; — details of the supporting payment infrastructure, as described in 5.1.

This document specifies an acceptable security framework for the issuance and management of digital currencies using cryptographic mechanisms standardized by ISO/TC 68/SC 2 and other references. This document proposes a framework approach based on standards for mitigating vulnerabilities for digital currency systems. The objective is that security aspects are integrated by design and not added afterwards as an extra processing layer that needs to accommodate legacy infrastructures.

This document specifies a common interface by which financial-transaction-card-originated messages can be interchanged between acquirers and card issuers. It specifies message structure and format, including normalized data types. Message, field, value definitions and supporting information are provided by the ISO 8583 maintenance agency (MA). Contact and web page information for the ISO 8583 MA can be found at: https://www.iso.org/maintenance_agencies.html. The method by which messages are transported or settlement takes place is not within the scope of this document. NOTE With the proliferation of technology available to financial institutions to offer services to customers, a range of tokens now exist for identifying account relationships (e.g. financial transaction cards). In order to maintain clarity, this document will continue to use card terminology that applies to tokens and cards, unless the element is specific to tokens or cards, in which case it will be identified as such. However, the actual token numeric issued by a financial institution can be different from the associated card numeric.

This document describes the management of cryptographic keys in a blockchain, or distributed system used in the financial sector The objective of this document is to consider the impact of different types of key management processes that are required for PKI implementations in Blockchain and DLT projects

This document specifies the security framework for using biometrics for authentication of customers in financial services, focusing exclusively on retail payments. It introduces the most common types of biometric technologies and addresses issues concerning their application. This document also describes representative architectures for the implementation of biometric authentication and associated minimum control objectives. The following are within the scope of this document: — use of biometrics for the purpose of: — verification of a claimed identity; — identification of an individual; — biometric authentication threats, vulnerabilities and controls; — validation of credentials presented at enrolment to support authentication; — management of biometric information across its life cycle, comprising enrolment, transmission and storage, verification, identification and termination processes; — security requirements for hardware used in conjunction with biometric capture and biometric data processing; — biometric authentication architectures and associated security requirements. The following are not within the scope of this document: — detailed specifications for data collection, feature extraction and comparison of biometric data and the biometric decision-making process; — use of biometric technology for non-financial transaction applications, such as physical or logical system access control.

This document defines code values used to enable the classification of merchants into specific categories based on the type of business, trade or services supplied. Values are specified only for those merchant categories that are generally expected to originate retail financial transactions. It is not within the scope of this document to mandate the use of merchant category codes in any given situation.

This document describes the management of symmetric and asymmetric cryptographic keys that can be used to protect sensitive information in financial services related to retail payments. The document covers all aspects of retail financial services, including connections between a card-accepting device and an Acquirer, between an Acquirer and a card Issuer, and between an ICC and a card-accepting device. It covers all phases of the key life cycle, including the generation, distribution, utilization, archiving, replacement and destruction of the keying material. This document covers manual and automated management of keying material, and any combination thereof, used for retail financial services. It includes guidance and requirements related to key separation, substitution prevention, identification, synchronization, integrity, confidentiality and compromise, as well as logging and auditing of key management events. Requirements associated with hardware used to manage keys have also been included in this document.

This document examines semantic enrichment to support the maintenance of the ISO 20022 conceptual model. It reports on existing and proposed practices to enrich a model: — in a repository, annotating repository concepts with metadata using semantic markup or constraints; — outside a repository, using references to repository concepts, such as the provenance of changes.

This document discusses the modes, related mainstream technologies, logical models, physical implementation models, data management (data storage and data security) and service quality control used in the reference data distribution in financial services. This document applies to the reference data distribution and transmission processes in financial services.

This document specifies checklists to be used to evaluate secure cryptographic devices (SCDs) incorporating cryptographic processes as specified in ISO 9564‑1, ISO 9564‑2, ISO 16609, and ISO 11568 in the financial services environment. Integrated circuit (IC) payment cards are subject to the requirements identified in this document up until the time of issue, after which they are to be regarded as a “personal” device and outside of the scope of this document.

This document provides guidelines for customer identification in mobile financial services (MFS), including: — a general framework of customer identification for MFS; — the multi-dimensional overall identity assurance level (AL) of an MFS customer and its evaluation criteria; — security and privacy considerations. This document also contains annexes which demonstrate how to apply the ALs in practice, through (e)KYC use cases in different regions, for example. This document is applicable to various kinds of MFS providers, including but not limited to commercial banks and third-party payment service providers. This document is applicable to identifying natural persons. Identifying legal entities, known as (e)KYB, is out of the scope of this document.

This document provides best practices for writing a banking products or services (BPoS) handbook. It is applicable to any providers of banking products or services (BPoSP) that issue and operate BPoS. NOTE 1 A BPoS handbook is edited by either product managers or personnel in charge of key elements mentioned in this document, based on their role and responsibility within the BPoSP. NOTE 2 Whether ISO 21586 has been formally introduced, this document is useful as existing BPoS contain the key elements listed in ISO 21586.

This document reports on a study to map messages defined using FIX Orchestra into the ISO 20022 model.

This document specifies procedures, independent of the transmission process, for protecting the integrity of transmitted financial-service-related messages and for verifying that a message has originated from an authorized source, or that stored data has retained integrity. A list of block ciphers approved for the calculation of a message authentication code (MAC) is also provided. The authentication methods defined in this document are applicable to stored data and to messages formatted and transmitted both as coded character sets or as binary data. This document is designed for use with symmetric algorithms where both sender and receiver use the same key. It does not specify methods for establishing the shared key. Its application will not protect the user against internal fraud perpetrated by the sender or the receiver, nor against forgery of a MAC by the receiver.

This document provides the normative specification of the FIX tagvalue encoding, which is one of the possible syntaxes for FIX messages.

This document provides a set of mandatory and optional conformity tests applicable to all versions of the FIX session layer standard.

This document provides the normative specification of the FIX session layer standard and its session profiles.

This document specifies the elements and structure of a universal identifier code, the business identifier code (BIC), for financial and non-financial institutions, for which such an international identifier is required to facilitate automated processing of information for financial services. The BIC is used for addressing messages, routing business transactions and identifying business parties. This document applies to organizations and excludes individual persons.

This document specifies an unambiguous scheme to list official organizational roles by jurisdiction in a standard way. It is not the purpose of this document to compare or align official organizational roles across different countries or jurisdictions, so as not to limit the usage or relevance of this document. To understand the powers associated with each official organizational role, users of this document can consult applicable regulation or legislation, documents of the legal entity in which the official organizational role exists and procedures specific to each organizational entity.

This document specifies the elements of an unambiguous scheme to identify over-the-counter (OTC) derivative products that are reportable to trade repositories, in particular: — the structure and format of the unique product identifier (UPI) code; — the minimum data elements of the UPI reference data library, together with their allowable values. At a minimum, the UPI code is applicable to OTC derivative instruments falling under the following categories of the classification of financial instruments (see ISO 10962): — swaps (S); — forwards (J); — non-listed and complex listed options (H); — others (miscellaneous) (M).

This document specifies a machine-readable, unambiguous natural person identifier (NPI) and the relevant reference data to uniquely identify the natural person relevant to any financial transaction rather than the personal identifying information.

This document defines the data elements included in the registry record and used to establish the 1:1 relationship between a digital token and the identifier assigned according to the method in ISO 24165-1.

This document defines the assignment and generation of a random, unique, fixed-length identifier for digital tokens in response to a request for registration that conforms to specified application guidelines (see also ISO 24165-2).

This document aims to provide an introduction to the topic of creating a conceptual model for storing multidimensional data which is received as XBRL instances that follow the rules defined by European taxonomies published by the European Banking Authority (EBA) or by the European Insurance and Occupational Pensions Authority (EIOPA).

This document provides guidelines for data point modelling for supervising experts. The main body consists of four sections. The interrogative form helps in choosing which section may best answer your question and lead you to a good understanding of the subject matter. After this first introductory section and the section containing terms and definitions, the main part starts to provide basic knowledge about different types of data models and data modelling approaches. The first and the second sections provide an overview of data models in general, in contrast to the third section that highlights the necessity of data modelling for supervisory data. This third section draws on the objectives and background information of the preceding sections. Furthermore, a paragraph classifies the Data Point Model introduced by the Eurofiling Initiative and elaborated by EIOPA and EBA, where many new terms related to DPM are introduced. Another paragraph explains the areas of application for the DPM. The third section concludes with a paragraph introducing a subset of the technical constrains that need to be considered in the creation process of the DPM. The fourth section gives step-by-step instructions on how to create a DPM. The paper concludes with remarks on the progress achieved so far, and provides an outlook on the software that is being developed at the moment to support you during the creation process.

This document defines the Data Point Methodology for the creation of Data Point Models in the context of European supervisory reporting. Data Point Models are published by a European supervisory authority. To reflect the defined structures in a machine-readable form, they can be accompanied by an XBRL taxonomy. It is also possible to extend the described methodology to other environments.

This document defines a common terminology to be used in the context of third-party payment (TPP). Next, it establishes two logical structural models in which the assets to be protected are clarified. Finally, it specifies security objectives based on the analysis of the logical structural models and the interaction of the assets affected by threats, organizational security policies and assumptions. These security objectives are set out in order to counter the threats resulting from the intermediary nature of TPPSPs offering payment services compared with simpler payment models where the payer and the payee directly interact with their respective account servicing payment service provider (ASPSP). This document assumes that TPP-centric payments rely on the use of TPPSP credentials and the corresponding certified processes for issuance, distribution and renewal purposes. However, security objectives for such processes are out of the scope of this document. NOTE This document is based on the methodology specified in the ISO/IEC 15408 series. Therefore, the security matters that do not belong to the TOE are dealt with as assumptions, such as the security required by an information system that provides TPP services and the security of communication channels between the entities participating in a TPP business.

This document defines and describes the structure for the codes for an internationally valid system to classify financial instruments. The classification system applies to financial instruments negotiated internationally as well as to domestic instruments. The term “financial instruments” refers not only to classical securities and derivatives but also covers the innovative financial products that have emerged in different markets (a trend that is expected to continue in the future). This document is intended for use in any application in the trading and administration of financial instruments in the international securities business. Insofar as the trading and administration of securities do not affect other countries, the application of this document remains at the discretion of the responsible national bodies, such as stock exchanges, banks, brokers, regulatory bodies and other institutions active in the securities field. In principle, the CFI code reflects characteristics that are defined when a financial instrument is issued and that remain unchanged during its entire lifetime. However, a few events that can lead to a new CFI code for the same instrument are anticipated, such as the changing of voting rights or ownership restrictions by a stockholders' meeting.

This document provides a uniform structure for the identification of financial instruments as well as referential instruments (see Annex A) using a unique identification code and associated minimum descriptive data (see Annex B).

This document describes the Registration Authority (RA) responsible for the registry of IBAN formats that conform with ISO 13616-1, the procedures for registering IBAN formats that conform with the ISO 13616 series and the structure of the registry.

This document specifies the elements of an international bank account number (IBAN) used to facilitate the processing of data internationally in data interchange, in financial environments as well as within and between other industries. The IBAN is designed for automated processing but can also be used conveniently in other media interchange when appropriate (e.g. paper document exchange). This document does not specify internal procedures, file organization techniques, storage media or languages to be used in its implementation, nor is it designed to facilitate the routing of messages within a network. It is applicable to the textual data which might be conveyed through a system (network).

This document specifies how to describe the characteristics of banking products or services (BPoS) from a customer's perspective. Characteristics of a BPoS can be observed from different facets, called key elements, which are divided into three groups: required, optional or voluntary elements. This document elaborates on the purpose, content and description approach for the required and optional key elements. Six levels of conformity are described in this document which are intended to allow a customer to assess the coverage of key elements in a BPoS. The logical and physical formats to express key elements are also defined. This document excludes requirements of a BPoS itself and specific value ranges of any key element are out of the scope. This document guides the provider of BPoS in describing their products or services with the intent to help customers understand or compare specific BPoS. It is not applicable to describing securities or insurance-related products or services. BPoS can be issued by banks and other institutions.

This document specifies a standardised way of embedding the legal entity identifier (LEI) code, as represented in ISO 17442-1, in digital certificates, represented by the International Telecommunications Union (ITU) Recommendation X.509 and its ISO equivalent standard, ISO/IEC 9594-8. This document specifies the structure of a public key certificate conforming with ISO/IEC 9594-8 in which the LEI is embedded.

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 capacity[1], but excludes natural persons. It also includes international branches as defined in 3.5. 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; — international branches; — all entities that issue equity, debt or other securities for other capital structures; — all entities listed on an exchange; — all entities that trade financial instruments or are otherwise parties to financial transactions, including business entities, pension funds and investment vehicles such as collective investment funds (at umbrella and sub-fund level) and other special purpose vehicles that have a legal form; — 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. [1] As stated by the LEI Regulatory Oversight Committee on 30 September 2015.

This document specifies the elements of an unambiguous scheme to identify a financial transaction uniquely whenever useful and agreed by the parties or community involved in the transaction. It does not specify the timing of assignment of who should be responsible for its generation, so as not to limit its usage or relevance, nor does it consider a need to establish a data record for the unique transaction identifier (UTI) itself.

This document defines the framework, function and protocols for an API ecosystem that will enable online synchronised interaction. Specifically, the document: — defines a logical and technical layered approach for developing APIs, including transformational rules. Specific logical models (such as ISO 20022 models) are not included, but they will be referenced in the context of specific scenarios for guidance purposes; — will primarily be thought about from a RESTful design point of view, but will consider alternative architectural styles (such as WebSocket and Webhook) where other blueprints or scenarios are offered; — defines for the API ecosystem design principles of an API, rules of a Web-service-based API, the data payload and version control; — sets out considerations relevant to security, identity and registration of an API ecosystem. Specific technical solutions will not be defined, but they will be referenced in the context of specific scenarios for guidance purposes; — defines architectural usage beyond query/response asynchronous messaging towards publish/subscribe to support advanced and existing business models. This document does not include: — a specific technical specification of an API implementation in financial services; — the development of JSON APIs based on the ISO 20022 specific message formats, such as PAIN, CAMT and PACS; — a technical specification that is defined or determined by specific legal frameworks.

This document describes a data element related to key management which can be transmitted either in transaction messages to convey information about cryptographic keys used to secure the current transaction, or in cryptographic service messages to convey information about cryptographic keys to be used to secure future transactions. This document addresses the requirements for the use of the data element related to key management within ISO 8583-1, using the following two ISO 8583-1 data elements for DEA and TDEA: — security related control information (data element 53); — key management data (data element 96). The data element related to key management for DEA and TDEA is constructed from the concatenation of two ISO 8583-1 message elements, data element 53 — security related control information, and data element 96 — key management data. It conveys information about the associated transaction's cryptographic key(s) and is divided into subfields including a control field, a key-set identifier and additional optional information. For AES implementations, the data elements are summarized in one field. This document is applicable to either symmetric or asymmetric cipher systems.

This document gives an overview of existing and currently used financial instrument identifiers. It shows which instrument identifiers, ticker symbols and proprietary codes are assigned via a standardized scheme to instruments of all asset classes. It focuses on providing an overview of the landscape and not on evaluating the schemes. Several aspects of the detailed trade cycle (a few examples being book building/primary, order entry management, execution management and trade confirmation matching) are excluded as their complexity would reduce the readability of the overview. Similarly, the level of complexity involved in properly representing the shifting perspectives of what is considered a financial instrument, based on a particular function being performed, is excluded.