DOCSLIB.ORG

Why Is There a Need for GSMA Mobile Money API Specification? a Comparison with Other Industry Standards

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Why Is There a Need for GSMA Mobile Money API Specification? a Comparison with Other Industry Standards Why is there a need for GSMA Mobile Money API Specification? A comparison with other industry standards July 2020 Copyright © 2020 GSM Association GSMA Mobile Money The GSMA represents the interests of mobile operators The GSMA’s Mobile Money programme works to accelerate worldwide, uniting more than 750 operators with almost the development of the mobile money ecosystem for the 400 companies in the broader mobile ecosystem, including underserved. handset and device makers, software companies, equipment providers and internet companies, as well as organizations For more information, please contact us: in adjacent industry sectors. Web: www.gsma.com/mobilemoney Twitter: @gsmamobilemoney The GSMA also produces the industry-leading MWC events Email: [email protected] held annually in Barcelona, Los Angeles and Shanghai, as well as the Mobile 360 Series of regional conferences. Inclusive Tech Lab: www.gsma.com/lab For more information, please visit the GSMA corporate website at www.gsma.com. Follow the GSMA on Twitter: @GSMA Authors: Viji Pathy, API Architect, Inclusive Tech Lab Bart-Jan Pors, Director, Inclusive Tech Lab, Mobile Money Gareth Pateman, Founding Partner, MFX THE GSMA MOBILE MONEY PROGRAMME IS SUPPORTED BY THE BILL AND MELINDA GATES FOUNDATION Why is there a need for GSMA Mobile Money API Specification? A comparison with other industry standards Contents Executive summary ................................................................................................. 5 01 Introduction ................................................................................................. 6 1.1. Mobile money industry growth ..............................................................................6 1.2. Growth of ecosystem integration with APIs .....................................................7 1.2.1. Mobile money ................................................................................................7 1.2.2. Financial services .........................................................................................7 1.3. Barriers to ecosystem integration with APIs ....................................................8 02 Financial services API standards .............................................................. 9 2.1. Evolution and growth of financial services and payments industry ........9 2.2. Financial services and payments industry standards ...................................11 2.2.1. ISO 8583 ..........................................................................................................11 2.2.2. ISO 20022 .......................................................................................................11 2.2.3. UK Open Banking [compliant with PSD2] .........................................11 2.2.4. Benefits of financial services API standards .....................................11 2.3. DFSP interoperability.................................................................................................12 2.3.1. Overview of DFSP interoperability .......................................................12 2.3.2. Mojaloop ..........................................................................................................12 2.3.3. Benefits of interoperability platforms ..................................................12 03 GSMA Mobile Money API Specification ................................................... 13 3.1. Introduction ...................................................................................................................13 3.2. Latest release scope ..................................................................................................13 04 Standards comparison ............................................................................... 14 4.1. Why analyse comparisons of API standards? ..................................................14 4.2. Introduction to analysis ............................................................................................14 4.3. Comparison analyses .................................................................................................14 4.3.1. Card payments - ISO 8583 .......................................................................16 4.3.2. Financial services - ISO 20022 ...............................................................17 4.3.3. Financial services - UK Open Banking [PSD2] .................................18 4.3.4. Mojaloop DFSP API ....................................................................................20 05 Conclusions .................................................................................................. 22 5.1. Benefits of API harmonisation in the mobile money industry ...................22 5.2. The need for the GSMA Mobile Money API Specification ...........................22 5.3. References .....................................................................................................................25 3 Why is there a need for GSMA Mobile Money API Specification? A comparison with other industry standards 4 Why is there a need for GSMA Mobile Money API Specification? A comparison with other industry standards Executive Summary Mobile money is a rapidly growing sector of the financial services industry across developing markets, having surpassed one billion accounts in 2019. Enabling seamless integrations of third parties with mobile money platforms via open Application Programming Interfaces (APIs) is a key catalyst to drive this growth and expand customer access to financial products and products with payment functionality. There are a variety of approaches that mobile money This paper examines these different approaches and providers could potentially use to deliver open APIs outlines the findings of detailed analysis undertaken to their ecosystem partners, such as creating their on the scope of the existing API standards and APIs, own bespoke APIs or utilising an existing API and how they compare with the GSMA API. Based on standard aimed at Digital Financial Services this examination and analysis, the paper argues that Providers (DFSPs). Mobile money providers can also adoption of the GSMA Mobile Money API integrate with interoperability software which offer Specification offers unique benefits for mobile DFSP APIs. The GSMA Mobile Money API (GSMA money providers and presents the optimum API) Specification offers an alternative approach. By approach for delivering open APIs. providing a harmonised API Specification for mobile money use cases developed in collaboration with the mobile money industry, it promotes an industry defined common API. 5 Why is there a need for GSMA Mobile Money API Specification? A comparison with other industry standards 01 Introduction 1.1. Mobile money industry growth Mobile money is a rapidly growing sector of the The history and growth of mobile money since its financial services industry across developing markets, inception 13 years ago, and especially the rapid having surpassed one billion accounts in 2019. The growth over the last five years (Figure 1), shows mobile money industry is over a decade old, and now that the industry has reached a critical stage includes a host of seasoned providers with a broad set in its evolution. The forecast for mobile money of operational capabilities, a full suite of products, and anticipates further growth and expansion.2 a global reach. With 290 live services in 95 countries and 371 million active accounts, mobile money is entering the mainstream. It is also becoming the path to financial inclusion in most low-income countries, with mobile money services available in 96 per cent of countries where less than a third of the population have an account at a formal financial institution.1 (Millions) 1 1 2 3 6 12 27 33 43 59 71 77 (+1M services) 1,200.00 1,000.00 1.039 billion Registered Accounts 800.00 600.00 400.00 371 million Active Accounts (90 Days) 200.00 261 million Active Accounts (30 Days) 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 1. Naghavi, N. (2020). State of the Industry Report on Mobile Money 2019. GSMA. 2. Ibid. 6 Why is there a need for GSMA Mobile Money API Specification? A comparison with other industry standards 1.2. Growth of ecosystem integration with APIs 1.2.1. Mobile money Drawing on best practices in other industries and Ecosystem development is likely to be a key driver pilots with several DFSPs, CGAP have outlined for industry growth. Over $1.9 billion is processed recommendations for open API offerings,7 from daily by mobile money platforms, and in 2019, for which it can be seen that platform providers need the first time, digital transactions represent the to consider a wide range of business, technical majority (57 per cent) of mobile money transaction and security factors to create a successful open values, with more money entering and leaving the API strategy. An industry-wide API definition system in digital form. One of the key reasons for could hugely benefit providers in this task. this is lower barriers to third party integration.3 One of the biggest challenges for open APIs is A GSMA API Landscape Survey completed in 2019 promoting uptake with third parties. A common analysed responses from 37 mobile money providers industry API could create an industry-wide globally covering over 260 million accounts. The ecosystem and community to facilitate this uptake. resulting report aimed to understand the main industry It could also be argued that there is a strong case trends in terms of third party integration
Load more

Recommended publications
  • POS Interface Specifications ISO 8583 (1987 Version)
    POS Interface Specifications ISO 8583 (1987 version) Prepared by: Nigeria Inter – Bank Settlement System (NIBSS) Version: 1.16 August 07, 2018 Page 1 of 64 POS ISO 8583 Interface Specification TABLE OF CONTENTS POS INTERFACE SPECIFICATIONS .................................................................................... 1 ISO 8583 (1987 VERSION) ............................................................................................... 1 DOCUMENT CONTROL .................................................................................................... 3 1. INTRODUCTION ....................................................................................................... 4 2. EXTERNAL MESSAGE TYPES ........................................................................................ 5 2.1 PROTOCOL ............................................................................................................ 5 2.2 BITMAP .................................................................................................................... 5 2. 3 SUPPORTED MESSAGE TYPE ......................................................................................... 5 3. EXTERNAL MESSAGE TYPE LAYOUTS ........................................................................... 6 3.1 AUTHORIZATION REQUEST/REPEAT (0100) ..................................................................... 6 3.2 AUTHORIZATION REQUEST RESPONSE (0110) .................................................................. 7 3.3 FINANCIAL REQUEST/REPEAT (0200) ..........................................................................
    [Show full text]
  • STATE of MICHIGAN CENTRAL PROCUREMENT SERVICES Department of Technology, Management, and Budget 525 W
    STATE OF MICHIGAN CENTRAL PROCUREMENT SERVICES Department of Technology, Management, and Budget 525 W. ALLEGAN ST., LANSING, MICHIGAN 48913 P.O. BOX 30026 LANSING, MICHIGAN 48909 CONTRACT CHANGE NOTICE Change Notice Number 1 to Contract Number 200000002198 Program Fidelity Information Services, LCC Manager Various MDHHS CONTRACTOR 601 Riverside Avenue STATE Jacksonville, FL 32204 Administrator Kim Bynan Contract Joy Nakfoor DTMB 414-577-9861 (517) 249-0481 [email protected] [email protected] VC0006630 CONTRACT SUMMARY ELECTRONIC BENEFITS TRANSFER (EBT) FOR SNAP AND WIC PROGRAMS INITIAL EFFECTIVE DATE INITIAL EXPIRATION DATE INITIAL AVAILABLE OPTIONS EXPIRATION DATE BEFORE November 1, 2020 September 14, 2027 1 - 3 Year September 14, 2027 PAYMENT TERMS DELIVERY TIMEFRAME N/A ALTERNATE PAYMENT OPTIONS EXTENDED PURCHASING ☐ P-Card ☐ PRC ☐ Other ☐ Yes ☒ No MINIMUM DELIVERY REQUIREMENTS N/A DESCRIPTION OF CHANGE NOTICE OPTION LENGTH OF OPTION EXTENSION LENGTH OF EXTENSION REVISED EXP. DATE ☐ ☐ September 14, 2027 CURRENT VALUE VALUE OF CHANGE NOTICE ESTIMATED AGGREGATE CONTRACT VALUE $22,655,691.55 $0.00 $22,655,691.55 DESCRIPTION Effective August 24, 2021, the new Go Live date is August 29, 2021. As of the Go Live, pricing is updated to: - SNAP CSR Cost per Minute is $0.699 (per the attached Schedule B – MDHHS SNAP Pricing, II. Call Center/Telecommunication). - WIC Cost per Case Month is $0.414 (per the attached Schedule B – MDHHS WIC Pricing, A. Cost Per Case Month). All other terms, conditions, specifications and pricing remain the same. Per contractor and agency agreement, and DTMB Central Procurement approval. CHANGE NOTICE NO. 1 TO CONTRACT NO.
    [Show full text]
  • Pre-Solicitation Instructions
    CALIFORNIA DEPARTMENT OF TECHNOLOGY PRE-SOLICITATION INSTRUCTIONS TO: All Interested Bidders RE: Pre-Solicitation Feedback DATE: November 9, 2016 The California Department of Technology (CDT) requests feedback and/or questions on the following Pre- Solicitation documents. FOR: ELECTRONIC WOMEN, INFANT AND CHILDREN MANAGEMENT INFORMATION SYSTEMS (eWIC MIS) PRE-SOLICITATION REVIEW 1. eWIC MIS Project Request for Proposal (RFP) in its entirety a. Part 1 – Bidders Instructions b. Part 2 – Bidders Response 2. Exhibit 22 – Cost Workbook Please note these documents are drafts and are subject to change. GENERAL QUESTIONS If the answer is yes to any of the questions below, please explain. 1. Are there any requirements for which assumptions are required to be made to provide a response? 2. Are there areas in the Statement of Work (SOW) that you believe are not clear? 3. Are there any Sections which are inconsistent and/or contradictory? 4. Is any additional information needed to prepare a response? REQUIREMENTS 1. Are there any requirements too onerous or which may result in unnecessary costs or risks to the State? If so, please indicate which ones and explain why. 2. Are there any requirements which may prevent you from submitting a response? If so, what are they, and why would they prevent you from responding? 3. Are there any requirements which may make it difficult to implement the solution by April 1, 2020? If yes, why? OTHER 1. Please provide a Rough Order of Magnitude (budgetary estimate) of the total costs for the solution required by this RFP. 2. Please review Section 5, Cost (Part 2) and Exhibit 22, Cost Worksheet, of the RFP and provide input on whether the Section and worksheet(s) are clear, concise, complete, and easy to use.
    [Show full text]
  • Technical Standards Catalogue VERSION 6.2
    e-Government Technical Standards Catalogue VERSION 6.2 FINAL September 2005 Technical Standards Catalogue / version 6.2 final / September 2005 1 CONTENTS 1 INTRODUCTION ...........................................................................................................................3 2 CHANGES FROM PREVIOUS VERSION..................................................................................4 3 ISSUES UNDER CONSIDERATION............................................................................................5 4 INTERCONNECTION ...................................................................................................................7 TABLE 1 SPECIFICATIONS FOR INTERCONNECTIVITY.......................................................................7 TABLE 2 SPECIFICATIONS FOR WEB SERVICES ..............................................................................10 5 DATA INTEGRATION ................................................................................................................16 TABLE 3 SPECIFICATIONS FOR DATA INTEGRATION ...........................................................................16 6 CONTENT MANAGEMENT METADATA ...............................................................................19 TABLE 4 SPECIFICATIONS FOR CONTENT MANAGEMENT METADATA .................................................19 TABLE 5 SPECIFICATIONS FOR IDENTIFIERS .......................................................................................20 7 E-SERVICES ACCESS.................................................................................................................23
    [Show full text]
  • Mobile and Contactless Payments Standards Glossary
    Mobile and Contactless Payments Standards Glossary Version 1.0 Publication Date: November 2019 U.S. Payments Forum ©2019 Page 1 About the U.S. Payments Forum The U.S. Payments Forum is a cross-industry body focused on supporting the introduction and implementation of EMV chip and other new and emerging technologies that protect the security of, and enhance opportunities for payment transactions within the United States. The Forum is the only non- profit organization whose membership includes the entire payments ecosystem, ensuring that all stakeholders have the opportunity to coordinate, cooperate on, and have a voice in the future of the U.S. payments industry. Additional information can be found at http://www.uspaymentsforum.org. EMV® is a registered trademark of EMVCo, LLC in the United States and other countries around the world. About the Mobile and Contactless Payments Working Committee The goal of the Mobile and Contactless Payments Working Committee is for all interested parties to work collaboratively to explore the opportunities and challenges associated with implementation of mobile and contactless payments in the U.S. market, identify possible solutions to challenges, and facilitate the sharing of best practices with all industry stakeholders. Copyright ©2019 U.S. Payments Forum and Secure Technology Alliance. All rights reserved. Comments or recommendations for edits or additions to this document should be submitted to: [email protected]. U.S. Payments Forum ©2019 Page 2 Table of Contents 1. Purpose of the Document
    [Show full text]
  • Open Terminal Requirement Specification 2006–07–01
    Technical Reference Guide – Open Terminal Requirement Specification 2006–07–01 Public Version © PBS A/S 1999–2006 i 2006–07–01 Technical Reference Guide – Open Terminal Requirement Specification Version 2.5 How to Contact PBS A/S PBS A/S Lautrupbjerg 10 DK–2750 Ballerup DENMARK Tel.no.: +45 44 68 44 68, att. PE 862 Chip og Terminaler Fax.no.: +45 44 86 09 30 E–mail: [email protected] Web–site: www.pbs.dk Disclaimers Copyright Information This document contains information proprietary to PBS A/S. The informa- tion, whether in the form of e.g. text, schematics, tables, drawings or illustra- tions, must not, without the prior, written consent of PBS A/S, be copied, re- produced or otherwise duplicated, disclosed outside the recipient company or organization or used by the recipient for purposes other than those explic- itly agreed in writing with PBS A/S. This limitation does not limit the recipient’s right to duplicate and use infor- mation contained in the document if such information is received from another source without restriction provided such source is not in breach of an obligation of confidentiality towards PBS A/S. Trademarks PBS and the PBS–logo are registered trademarks of PBS A/S. Dankort, VISA, Eurocard, MasterCard and Maestro names and logos are registered trademarks of PBS A/S and its international partners. Limitation of Liability Under no circumstances shall PBS A/S be liable for any direct incidental, in- direct, special or consequential damages whatsoever (including but not lim- ited to lost profits) arising out of or relating to this document or the informa- tion contained in it, even if PBS A/S has been advised, knew or should have known of the possibility of such damages.
    [Show full text]
  • ISO 8583-1:2003(E) This Is a Free 12 Page Sample
    INTERNATIONAL ISO STANDARD 8583-1 First edition 2003-06-15 Financial transaction card originated messages — Interchange message specifications — Part 1: Messages, data elements and code values Messages initiés par cartes de transaction financière — Spécifications d'échange de messages — Partie 1: Messages, éléments de données et valeurs de code Reference number ISO 8583-1:2003(E) This is a free 12 page sample. Access the full version online. © ISO 2003 www.standards.com.au Copyright ISO www.isostandards.com.au ISO 8583-1:2003(E) PDF disclaimer This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this area. Adobe is a trademark of Adobe Systems Incorporated. Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below. © ISO 2003 All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member body in the country of the requester.
    [Show full text]
  • ISO 20022 for Dummies, 2Nd Edition
    ISO 20022 2nd Edition ISO 20022 2nd Edition by The SWIFT Standards Team ISO 20022 For Dummies, 2nd Edition Published by John Wiley & Sons, Ltd The Atrium Southern Gate Chichester West Sussex PO19 8SQ England For details on how to create a custom For Dummies book for your business or organisation, contact [email protected]. For information about licensing the For Dummies brand for products or services, contact BrandedRights&[email protected]. Visit our Home Page on www.customdummies.com Copyright © 2013 by John Wiley & Sons Ltd, Chichester, West Sussex, England All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except under the terms of the Copyright, Designs and Patents Act 1988 or under the terms of a licence issued by the Copyright Licensing Agency Ltd, 90 Tottenham Court Road, London, W1T 4LP, UK, without the permission in writing of the Publisher. Requests to the Publisher for per- mission should be addressed to the Permissions Department, John Wiley & Sons, Ltd, The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, England, or emailed to [email protected], or faxed to (44) 1243 770620. Trademarks: Wiley, the Wiley logo, For Dummies, the Dummies Man logo, A Reference for the Rest of Us!, The Dummies Way, Dummies Daily, The Fun and Easy Way, Dummies.com and related trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries, and may not be used without written permission.
    [Show full text]
  • Security Rules and Procedures Merchant Edition 5 February 2015 Notices
    Security Rules and Procedures Merchant Edition 5 February 2015 Notices Notices Proprietary Rights The information contained in this document is proprietary and confidential to MasterCard International Incorporated, one or more of its affiliated entities (collectively “MasterCard”), or both. This material may not be duplicated, published, or disclosed, in whole or in part, without the prior written permission of MasterCard. Trademarks Trademark notices and symbols used in this document reflect the registration status of MasterCard trademarks in the United States. Please consult with the Customer Operations Services team or the MasterCard Law Department for the registration status of particular product, program, or service names outside the United States. All third-party product and service names are trademarks or registered trademarks of their respective owners. Disclaimer MasterCard makes no representations or warranties of any kind, express or implied, with respect to the contents of this document. Without limitation, MasterCard specifically disclaims all representations and warranties with respect to this document and any intellectual property rights subsisting therein or any part thereof, including but not limited to any and all implied warranties of title, non-infringement, or suitability for any purpose (whether or not MasterCard has been advised, has reason to know, or is otherwise in fact aware of any information) or achievement of any particular result. Without limitation, MasterCard specifically disclaims all representations and warranties that any practice or implementation of this document will not infringe any third party patents, copyrights, trade secrets or other rights. Translation A translation of any MasterCard manual, bulletin, release, or other MasterCard document into a language other than English is intended solely as a convenience to MasterCard customers.
    [Show full text]
  • Security Rules and Procedures—Merchant Edition • 27 February 2020 2 Contents
    Security Rules and Procedures Merchant Edition 27 February 2020 SPME Contents Contents Chapter 1: Customer Obligations........................................................................ 8 1.1 Compliance with the Standards....................................................................................9 1.2 Conflict with Law.........................................................................................................9 1.3 The Security Contact.................................................................................................... 9 1.4 Connecting to Mastercard—Physical and Logical Security Requirements....................... 9 1.4.1 Minimum Security Requirements.........................................................................10 1.4.2 Additional Recommended Security Requirements................................................11 1.4.3 Ownership of Service Delivery Point Equipment.................................................. 11 1.4.4 Component Authentication................................................................................ 11 Chapter 2: Cybersecurity Standards and Programs..................................12 2.1 Cybersecurity Standards............................................................................................. 13 Cybersecurity Minimum Requirement.......................................................................... 13 Cybersecurity Best Practice.......................................................................................... 13 2.1.1 Payment Card Industry
    [Show full text]
  • Guidelines on Cryptographic Algorithms Usage and Key Management
    EPC342-08 Version 8.0 18 December 2018 [X] Public – [ ] Internal Use – [ ] Confidential – [ ] Strictest Confidence Distribution: Publicly available GUIDELINES ON CRYPTOGRAPHIC ALGORITHMS USAGE AND KEY MANAGEMENT Abstract This document defines guidelines on cryptographic algorithms usage and key management. Document EPC342-08 Reference Issue Version 8.0 Date of Issue 18 December 2018 Reason for Issue Publication on EPC website Produced by PSSG Authorised by EPC Conseil Européen des Paiements AISBL– Cours Saint-Michel 30A – B 1040 Brussels Tel: +32 2 733 35 33 – Fax: +32 2 736 49 88 Enterprise N° 0873.268.927 – www.epc-cep.eu – [email protected] © 2016 Copyright European Payments Council (EPC) AISBL: Reproduction for non-commercial purposes is authorised, with acknowledgement of the source Document History This document was first produced by ECBS as TR 406, with its latest ECBS version published in September 2005. The document has been handed over to the EPC which is responsible for its yearly maintenance. DISCLAIMER: Whilst the European Payments Council (EPC) has used its best endeavours to make sure that all the information, data, documentation (including references) and other material in the present document are accurate and complete, it does not accept liability for any errors or omissions. EPC will not be liable for any claims or losses of any nature arising directly or indirectly from use of the information, data, documentation or other material in the present document. 2 EPC342-08 v8.0 Approved Guidelines on cryptographic algorithms usage and key management_final TABLE OF CONTENT MANAGEMENT SUMMARY ....................................................................................................... 6 1 INTRODUCTION ................................................................................................................ 8 1.1 Scope of the document .............................................................
    [Show full text]
  • Standards Analysis Ict Sector Luxembourg
    STANDARDS ANALYSIS ICT SECTOR LUXEMBOURG Version 7.0 · March 2017 · ISSN 2354-483X 2 WHITE PAPER · DIGITAL TRUST · Version 3.0 · October 2016 Executive summary In 2012 the “Institut Luxembourgeois de la Normalisation, de l’Accréditation, de la Sécurité et qualité des produits et services” (ILNAS) initiated an analysis of European and international standards in the Information and Communication Technology (ICT) sector. The aim of this analysis is to develop an information and exchange network for ICT standardization knowledge in the Grand Duchy of Luxembourg. Since 2013, this analysis has been carried out in the frame of the implementation of the “Luxembourg’s policy on ICT technical standardization” (which was last updated in 2015)1. The ICT sector is already involved at the national standardization level with 69 national delegates currently registered by ILNAS2. These delegates participate in standardization technical committees and follow closely the work performed at international level. Moreover, the national delegates also ensure that the views and positions of Luxembourg are understood and known by the technical committees. ILNAS recognizes the effort and support provided by this network of experts. Nevertheless, ILNAS is convinced that this sector could be more represented in terms of delegates and experts in technical standardization, especially since some ICT areas do not yet benefit from a sufficient representation of national delegates (e.g.: Internet of Things, Cloud Computing, Big Data, Smart Cities). Thus, the purposes of this analysis are firstly, to provide useful information to national stakeholders regarding standardization activities in the field of ICT and secondly, to attract and involve them into an integrated and innovative approach of standardization.
    [Show full text]