Archivo de la categoría: Banca 2.0

Sandbox regulatorio: Una oportunidad de negocio


Sabadell-Hub-EmpresaEl próximo 6 de julio a las 17:30h tedrá lugar un evento online impulsado por el Colegio Oficial de Ingenieros de Telecomunicación Región de Murcia y el Hub Empresa de Banco Sabadell, con el título Sandbox regulatorio: Una oportunidad de negocio.

Hay que inscribirse en este enlace.

Colegio de Ingenieros de Teleco - MurciaEn esta sesión hablaremos del Sandbox regulatorio como punta de lanza de la creación de un nuevo modelo de negocio que aflora infinidad de oportunidades empresariales.

En esta sesión, moderada por Fernando Canos, Director Comercial Territorial Este en Banco Sabadell, contaremos con las siguientes intervenciones:

  • Denis Nakagaki, Head of Digital Strategy and Partnerships de Innocells by Banco Sabadell: “Sandbox regulatorio como palanca para acelerar la innovación y acompañar mejor a nuestros clientes
  • Juan Luis Pedreño, Decano del Colegio de Ingenieros de Telecomunicación Región de Murcia, Catedrático de la Universidad Politécnica de Cartagena y Diputado Nacional en el Congreso de los Diputados: “Sandbox regulatorio en España, atracción de proyectos para el desarrollo de la Transformación Digital” –
  • Julian Inza, Chief Audit Officer de TCAB (Trust Conformity Assessment Body): “Sandbox regulatorio para mejorar la competitividad de la innovación Fintech, Insurtech, Regtech, Suptech desde España”.

El Grupo de Expertos de la Comisión Europea sobre los obstáculos normativos a la innovación financiera insta a la UE para que empiece las reformas legales ya


El Grupo de Expertos de la Comisión Europea sobre los obstáculos reglamentarios a la innovación financiera (Expert Group on Regulatory Obstacles to Financial Innovation – ROFIEG)  insta a la reforma de la normativa financiera de la UE para fomentar la innovación en el sector de las finanzas.

El pasado 13 de diciembre de 2019 se ha publicado su esperado informe sobre cómo mejorar y fortalecer el panorama europeo del sector FinTech y sobre como fomentar una mayor inversión e innovación, además de poner fin a la fragmentación normativa y establecer un marco regulatorio más sólido.

Compuesto por expertos del sector, representantes de  instituciones financieras, académicos y juristas, junto con observadores de organismos como la ABE, la AEVM y el BCE, el Grupo de Expertos ha estado trabajando desde junio de 2018 en la creación de un marco de adaptación para el sector FinTech en la UE. El informe contiene 30 recomendaciones de medidas legislativas y no legislativas para abordar los problemas que actualmente obstaculizan la adopción o la ampliación del sector FinTech en toda la UE. Entre ellas se incluyen acciones para facilitar el uso de la IA (Inteligencia Artificial) y las tecnologías asociadas, las DLT (tecnologías de tipo blockchain) y los criptoactivos  e impulsar ámbitos conexos como RegTech y SupTech. También se recomiendan acciones para fortalecer el marco de acceso, intercambio y procesamiento de datos.

“En general, las recomendaciones tienen por objeto apoyar un marco más flexible y tecnológicamente neutro para el sector FinTech en toda la UE, que permita aprovechar las ventajas de las tecnologías afines al sector financiero y, al mismo tiempo, mitigar eficazmente el riesgo”, nos explica Elisabeth Noble, Asesora Principal de Políticas de la EU Banking Authority (Autoridad Bancaria de la UE) y uno de los miembros del Grupo de Expertos.

Actualmente, la UE acoge sólo el 5% del valor global de las empresas tecnológicas, frente al 65% de Estados Unidos y el 35% de China, y el grupo ha criticado el marco regulatorio actual tildándolo de “ausente, fragmentado o poco claro” que impide que los mercados financieros de la UE pongan en valor los beneficios de los avances tecnológicos. “La competitividad y la soberanía regulatoria en relación con un sector financiero que hiciera un mayor uso de la tecnología requieren un marco considerablemente más armonizado sobre la base de los axiomas regulatorios existentes que el que existe actualmente en la UE”, advierte el informe.

El informe propone la creación de una “agenda exhaustiva y ambiciosa” para apoyar la adopción de tecnologías digitales por reguladores y supervisores en lo que se denomina  RegTech (tecnología en el ámbito de la regulación financiera) y SupTech (tecnología en el ámbito de la supervisión financiera) para enmarcar el impulso al sector financiero,  así como la adopción de una estrategia para hacer que los procesos de envíos de informes al regulador y al supervisor y las obligaciones de cumplimiento legal cuenten con versiones procesables por máquina así como destinadas a la lectura por humanos.

También recomienda el establecimiento de cámaras de compensación regulatorias para centralizar la difusión de las normas a las entidades reguladas, recibir información sobre incidentes e informes regulatorios y recopilar datos de mercado, junto con la creación de una nueva “regulatory sandbox” (entorno de pruebas supervisado por el regulador)  a nivel de la UE para apoyar la innovación y la estandarización.

Según el grupo de expertos, los procesos KYC (Know Your Customer, conoce a tu cliente) deberían armonizarse plenamente en todos los Estados miembros,  mientras que la diligencia debida con respecto a los clientes (CDD, customer due diligence) y la incorporación de éstos a las propias entidades financieras y Fintech (lo que se denomina “client onboarding”)  también podrían regularse y se podría introducir legislación expresa como ya ocurre en algunos países como España, sobre la verificación de la identidad digital. Entre las recomendaciones se incluyen  aspectos sobre el intercambio y procesamiento de datos proponiendo el uso obligatorio de interfaces estandarizadas de intercambio de datos.

Desde el punto de vista regulatorio, el informe subraya que, si bien la legislación de la UE sobre servicios financieros debería ser “tecnológicamente neutra, suficientemente preparada para el futuro y apta para su finalidad”, no tiene mucho sentido crear marcos específicos para la tecnología (como una “reglamentación de la cadena de bloques” blockchain) y la cuestión debería abordarse en cambio desde una perspectiva temática. Hay cinco temas sobre los que se sugieren recomendaciones:  la comprensión de la tecnología y su impacto, la ciberresiliencia (resistencia los ataques cibernéticos), la subcontratación, la gobernanza de las redes financieras distribuidas (incluyendo el marco legal para los cripto-activos), y la estandarización en lo que respecta a RegTech y SupTech.

En el espacio RegTech, es notable que entre 2008-2016, hubo un aumento del 500% en los cambios regulatorios en los mercados desarrollados, lo que evidencia la necesidad de soluciones RegTech escalables, fiables y eficientes. A medida que las empresas buscan reducir las cargas de cumplimiento legal y minimizar las sanciones regulatorias, las investigaciones predicen que en los próximos años el gasto en RegTech crecerá en un 48% anual, pasando de 10.600 millones de dólares en 2017 a 76.300 millones en 2022. Y eso que, según el grupo de expertos, “el marco actual es ineficiente”, particularmente en lo que se refiere a los requisitos de presentación de informes.

“Un enfoque proactivo para aportar claridad sobre las expectativas de regulación y supervisión de la adopción de FinTech en el sector financiero puede fomentar la inversión al proporcionar la tan deseada certidumbre”, afirma la señora Noble. “Al crear estas condiciones que permitan a las empresas escalar más fácilmente a nivel transfronterizo, las empresas estarán mejor situadas para aprovechar el mercado local y convertirse potencialmente en campeonas no sólo de la UE, sino también del mundo”.

El informe recomienda la introducción de pautas legislativas legibles y ejecutables por máquina, incluyendo la estandarización de instrucciones regulatorias en una versión ejecutable por máquina que pueda facilitar la generación de informes a los supervisores automatizada. Este aspecto posiblemente requiera el desarrollo de un lenguaje de especificaciones para generación de informes que sirva de base a este tipo de iniciativas. También deben considerarse soluciones automatizadas y de Inteligencia Artificial para la entrada, agregación y análisis de datos, incluyendo soluciones que permitan el “procesamiento directo” de las declaraciones reglamentarias. Y las cámaras de compensación regulatorias ya mencionadas deberían trabajar en la vinculación entre la regulación, los procesos de cumplimiento y la elaboración de informes a los supervisores para fomentar que estos sean más rápidos, precisos y de menor coste, haciendo que la  regulación y la supervisión sean más eficaces.

“La adopción de soluciones RegTech y SupTech comunes basadas en normas técnicas ayudaría a las empresas (por ejemplo, en la información regulatoria diaria), a los supervisores (por ejemplo, en el análisis de informes sobre transacciones sospechosas, datos notificados y datos compartidos a nivel transfronterizo) y a las AES, Agencias Supervisoras Europeas, European Supervisory Agencies  (por ejemplo, en el contexto de la notificación de datos para los ejercicios de pruebas de estrés  y la supervisión de los riesgos macroprudenciales)”, concluye.

Entre las recomendaciones también se incluyen: una taxonomía común que permita armonizar diferentes clasificaciones de servicios, un enfoque reglamentario unificado y una norma que establezca la precedencia normativa que ayude a minimizar situaciones de conflicto de leyes para los cripto-activos; la supervisión de la subcontratación externa por parte de las instituciones financieras de servicios esenciales a fin de mitigar los riesgos de concentración; la elaboración de un nuevo marco de pruebas de ciberresiliencia para el sector financiero; y la publicación de pautas orientativas sobre normas para la tecnología de la inteligencia artificial.

“Ninguna de nuestras recomendaciones son soluciones rápidas”, advierte el presidente del Grupo de Expertos Philipp Paech. “Algunas incluso pueden ser bastante complejas en términos de implementación. Aún así, estamos convencidos de que la UE no debería restringir sus iniciativas hacia los objetivos que parecen más al alcance de la mano, sino que debería apostar por por una visión a largo plazo que logre de forma sostenida  que su sector financiero sea competitivo en todo momento, lo que beneficiará a los ciudadanos”.

Los miembros del Grupo de Expertos son:
Type A – Individual expert appointed in his/her personal capacity

Name Nationality Professional Title Membership Status
Philipp Paech Germany Director Law and Financial Markets Project Member

Type B – Individual expert appointed as representative of a common interest

Name Nationality Professional Title Membership Status
Sofie Van de Velde Belgium Head of Legal support Member
Thomas Jantsch Germany Attorney-at-Law Member
Simon Maisey United Kingdom Managing Director and Global Head of Business Development Member

Type C – Organisation

Name of Organisation Category Countries/Areas represented Membership Status
AXA Banks/Financial Institutions
France
Member
BANCO BILBAO VIZCAYA ARGENTARIA (BBVA) Banks/Financial Institutions
Spain
Member
Barclays PLC Banks/Financial Institutions
United Kingdom
Member
Deutscher Sparkassen-und Giroverband (DSGV) Banks/Financial Institutions
Germany
Member
FinLeap GmbH Companies/Groups
Austria
Member
France Fintech Banks/Financial Institutions
France
Member
ING Group Banks/Financial Institutions
Netherlands
Member
London Stock Exchange Group (LSEG) Banks/Financial Institutions
United Kingdom
Member
Università Cattolica del Sacro Cuore (UCSC) Academia, Research Institute and Think Tanks
Italy
Member
University College Cork, National University of Ireland, Cork (UCC) Academia, Research Institute and Think Tanks
Ireland
Member

Type E – Other public entity

Name of Organisation Entity type Countries/Areas represented Membership Status
Committee on Payments and Market Infrastructures International/Intergovernmental Organisations
European
Observer
European Banking Authority EU Institutions/Bodies
European
Observer
European Central Bank EU Institutions/Bodies
European
Observer
European Insurance and Occupational Pensions Authority EU Institutions/Bodies
European
Observer
EUROPEAN SECURITIES & MARKETS AUTHORITY EU Institutions/Bodies
European
Observer

 

 

TPP, AISP, PISP, ASPSP – Términos de PSD2 y eIdAS


La entrada en vigor de la Segunda Directiva de Pagos (PSD2) recogida en la legislación española en el Real Decreto-ley 19/2018, de 23 de noviembre, de servicios de pago y otras medidas urgentes en materia financiera, permite el desarrollo de nuevos servicios financieros en Europa e impulsa un nuevo marco de competencia.

Aparecen nuevos términos, que conviene conocer en inglés y en español para entender mejor el nuevo contexto competitivo marcado por el “Open Banking”.

Término Descripción
AIS Account Information Services. Servicios de Información de Cuentas. Servicios accesibles mediante API (Application Program Interface) para los TPP (Third Party Provider) Prestadores Financieros  en los que obtener información de los usuarios de servicios de pago.
AISP Account Information Service Provider. Proveedor de servicios de información sobre cuenta.  Prestador Financiero que obtiene información de varias entidades en nombre de un usuario de servicios de pago y se las presenta de forma consolidada.
API Application Programming Interface. Interfaz de Programación de Aplicación. Una API proporciona a una entidad una forma sistemática de obtener información o iniciar acciones en otra entidad. Mediante parámetros y opciones pueden programarse diferentes servicios a terceros.
ASPSP Account Servicing Payment Service Provider.  Proveedor de servicios de pago gestor de cuenta. Una entidad financiera en la que un usuario de servicios de pago tiene cuentas a cuya información un Prestador Financiero puede acceder en su nombre o en la puede iniciar una transferencia.
Autenticacion El proceso de confirmar la identidad de un Prestador Financiero o de un usuario de servicios de pago. Existen pautas como SCA – Strong Customer Authentication (Autenticación Reforzada de Cliente) o mecanismos como los certificados eIdAS para garantizar la correcta identificación.
Autorización El proceso de confirmar la  funcionalidad permitida según las credenciales de un Prestador Financiero o de un usuario de servicios de pago. Inicialmente la funcionalidad se limita a acceder a información de cuentas o iniciar transferencias, según el tipo de prestador (AISP o PISP).
Consentimiento El acuerdo por el que el usuario de servicios de pago otorga al Prestador la posibilidad de acceder a su información bancaria o iniciar transferencias.
eIdAS Reglamento UE 910/2014 que regula, entre otros aspectos los requisitos de expedición de certificados cualificados QWAC para sitios web y certificados cualificados para sello electrónico de los diferentes Prestadores. Los certificados los expiden  QTSPs – Qualified Trust Service providers, Prestadores cualificados de servicios electrónicos de confianza
NCA National Competent Authority. Autoridad Nacional Competente.  Organismo regulador o supervisor de entidades financieras que autoriza a un Prestador Financiero a operar en el nuevo marco de servicios financieros PSD2 cuando cumpla ciertos requisitos. En España, es el Banco de España.
PIS Payment Initiation Services. Servicios de iniciación del pagos. Servicios de transferencia bancaria gestionados por un Prestador Financiero en nombre de un usuario de servicios de pago a través de una API ofrecida por su Proveedor de servicios de pago gestor de cuenta.
PIIS Payment Issuer Instrument Service. Servicio asociado a medio de pago para solicitar por API la autorización de pago con tarjeta indicando el importe (comprueba la validez de la tarjeta y la disponibilidad del importe).
PISP Payment Initiation Service Provider. Proveedor de servicios de iniciación de pago. Prestador Financiero de servicios de transferencia bancaria gestionados en nombre de un usuario de servicios de pago a través de una API ofrecida por su Proveedor de servicios de pago gestor de cuenta. Puede requerirse por parte del ASPSP la confirmación del usuario.
PSU Payment Service User. Usuario de servicios de pago.
QTSP Qualified Trust Service Provider. Prestadores cualificados de servicios electrónicos de confianza. Expiden certificados cualificados QWAC para sitios web y certificados cualificados para sello electrónico de los diferentes Prestadores Financieros. Los certificados permiten identificar a los Prestadores Financieros cuando usan las APIs de otras entidades en entornos de Producción.
SCA Strong Customer Authentication. Autenticación Reforzada de Cliente. Proceso de confirmar la identidad del usuario. Normalmente se usan dos o más factores de autenticación:

  • “Algo que sabes”
  • “Algo que tienes”
  • “Algo que te caracteriza”
Sandbox Experimentos con gaseosa. Zona de pruebas.

El término en inglés Sandbox se refiere a una zona de juegos para niños en la que no estropean nada ni se hacen daño.  Se amplía a usos profesionales en los que se prueban desarrollos con funcionalidades similares a las del entorno real antes del paso a producción.

TPP Third Party Provider. Prestador Financiero. AISP o PISP.  Actúa en nombre de un usuario de servicios de pago accediendo a su información bancaria en otra entidad o iniciando una transferencia. Requiere una licencia por parte de una NCA y puede operar en otros países en virtud del concepto de “pasaporte” haciendo uso de certificados eIdAS.

Prestador-Financiero

Resuelto uno de los frenos a los certificados cualificados de PSD2


EIDAS-CAB-forumEl CAB Forum ha aprobado una modificación del documento “Extended Validation Guidelines” para permitir incluir guiones en el campo rganizationIdentifier (OID 2.5.4.97) de los certificados EV, con lo que los certificados expedidos en el contexto de la norma ETSI TS 119 495 ya no serán incompatibles con las comprobaciones que realizan los navegadores. De esta forma se podrán expedir certificados QWAC para entidades financieras y otras entidades que operan en aplicación de la Directiva (UE) 2015/2366 llamada Segunda Directiva de Pagos (PSD2).

La propuesta SC17 se ha aprobado con 23 votos favorables de entidades emisoras de certificados y 6 de las entidades desarrolladoras de navegadores (comprobadores de certificados).

Votos a favor:

  • Emisores:  Actalis, Buypass, Camerfirma, Certigna (DHIMYOTIS), Certum (Asseco), Chunghwa Telecom, Comsign, D-TRUST, DarkMatter, DigiCert, eMudhra, Entrust Datacard, Firmaprofesional, GDCA, GlobalSign, GoDaddy,  SHECA, SSC, SecureTrust (anteriormente Trustwave), TurkTrust.
  • Comprobadores: Apple, Cisco, Google, Microsoft, Mozilla, 360

1 Abstención (Emisores): TrustCor

Con este resultado, se permite la inclusión de información adicional en los certificados EV para cumplir con ciertas regulaciones de la Unión Europea.

La motivación argumentada que dio lugar a la solicitud que se ha votado fue:

  • El Reglamento de la Unión Europea Nº 910/2014 (eIDAS)  define ciertos requisitos reglamentarios para los certificados con un nivel de calidad acordado denominado “Cualificado”. Este reglamento especifica en el Anexo IV los requisitos específicos para “Certificados cualificados para la autenticación de sitios web”, incluida la declaración de que el certificado contendrá: “para personas jurídicas: al menos el nombre de la persona jurídica a la que se expida el certificado y, cuando proceda, el número de registro, tal como se recojan en los registros oficiales;
  • Se entiende que este requisito se relaciona con los atributos validados para la identificación del sujeto del certificado y, por lo tanto, se ajusta mejor al nombre distinguido del sujeto (subject’s distinguished name).
  • En línea con el marco regulatorio, ETSI ha definido una estructura general para llevar “números de registro” en la norma TS 119 412-1 (en la actualidad EN 319 412-1). Ver cláusula 5.1. 4. En ella se utiliza el identificador de organización (organizationIdentifier) de la norma  X.520 dentro del nombre distinguido del  sujeto el propósito de servir como “identificación de una organización diferente del nombre de la organización”. Esto se utiliza para los requisitos de ETSI para llevar los números de registro para certificados, cualificados o de otro tipo.
  • Se considera que este uso de organizationIdentifier es compatible con el propósito principal de los certificados de EV como se indica en la sección 2.1.1 de las Directrices de EV como “otra información desambiguadora”.
  • Un reciente Reglamento delegado de la UE 2018/389 sobre comunicaciones seguras para servicios de pago establece en el artículo 34.2 que para los Certificados de sitio web cualificados (QWAC), el número de registro requerido en eIDAS “será el número de autorización del proveedor de servicios de pago (…) o equivalente [referencia hecha a regulaciones anteriores relacionadas con entidades financieras]”.
  • ETSI ha especificado los requisitos de la norma TS 119 495 para incluir los números de registro relacionados con PSD2 en la estructura general para los números de registro definidos en la citada norma TS 119 412-1 en su cláusula 5.1 .4
  • ETSI se ha esforzado por garantizar y siempre ha intentado que los requisitos relacionados con los certificados de sitios web en el nivel Calificado estén en línea con las pautas de Extended Validation de CA / B Forum.
  • Esta propuesta solo incluye algunos de los Esquemas de registro utilizados en la norma ETSI TS 119 412-1, que tienen reglas de validación claras (NTR, IVA, PSD) que brindan una seguridad razonable de acuerdo con las “EV Guidelines”. Se propone que los IPR (intellectual property rights) para la semántica de este esquema se cedan al CA / B Forum, lo que le permitirá extender aún más el uso del Identificador de la organización (organizationIdentifier) para incluir otros Esquemas de registro (por ejemplo, LEI, Legal Entity Identifier) y las reglas de validación correspondientes, a discreción del CA / B Forum.  Además, cualquier cambio futuro realizado por ETSI a la norma ETSI TS 119 412-1 ya no tendrá impacto adicional en CA / B Forum.
  • Al tomar conciencia de que la interpretación del CA / B Forum de los “Requisitos de EV” en la sección 9.2.8 “Otros Atributos” no estaba en línea con la forma de entenderlos por los expertos de ETSI, este organismo desearía armonizar su interpretación con la de CA / B Forum para reflejar en los certificados diferentes formas de establecer números de registro para PSD2 y otros esquemas de identificación alfanumérica de entidades.

Por otro lado, las preocupaciones específicas del CA / B Forum eran:

  • Los requisitos con respecto a los atributos que se han de incluir en el DN (Distinguished Name) del sujeto deben recogerse de forma explícita en el apartado 9.2.
  • Las organizaciones pueden desear identificar las unidades organizativas dentro de su organización. No está claro si esto está permitido actualmente en las Directrices de EV (ambigüedad similar a la de la sección 9.2.8).
  • Se han argumentado objeciones al uso específico de ETSI del campo Distinguished Name.
  • Los procedimientos para la validación del atributo deben estar claramente establecidos.
  • Puede haber otros usos del campo OrganizationIdentifier  en varias PKI, sin embargo, no se considera un problema. dado que la semántica única que se está especificando para cada identificador, las aplicaciones deben ser capaces de comprender los diferentes usos del campo organizationIdentifier  por diferentes emisores y usuarios. Hay muchas “PKI” diferentes que pueden usar todos los atributos de X.500 de manera diferente y con una validación diferente o sin ninguna validación. Según parece, el WebPKI no ha usado anteriormente este atributo de subjectDN antes para los Certificados de confianza pública (Publicly-Trusted Certificates). Por lo tanto, no hay “conflicto” al usar este atributo en las Directrices EV para Certificados SSL / TLS, y tal vez más adelante para Certificados de Firma de Código EV.
  • Este uso de OrganisationIdentifier debe ser extensible para permitir el uso de otros números de registro asignados por diferentes esquemas de registro. Algunos miembros de CAB Forum han expresado interés en incluir números de registro que no sean para identificar el tipo de sociedad dentro de Certificados EV. Esto está previsto en la propuesta actual.
  • Algunos miembros del CA / B Forum tienen interés en llevar incluir las identificaciones LEI dentro de los certificados del CA / B Forum, pero hasta ahora el esquema de registro LEI no se considera lo suficientemente extendido como para ser reconocido como un esquema de numeración de registro para ser aceptado por el CA / B Forum. Por lo tanto, esta propuesta solo introduce un conjunto limitado de esquemas de registro (a saber, NTR, IVA, PSD) que tienen reglas de validación razonablemente sólidas.
  • Algunos miembros del CA / B Forum han indicado la posible necesidad de múltiples identificadores en el campo “nombre del sujeto”. Sin embargo, esto no se puede lograr utilizando el campo definido en la norma X.520 organizationIdentifier que definió este atributo como “SINGLE VALUE”.

Los cambios aprobados, que se reflejarán el documento “EV Guidelines” son:

  • Agregar a la sección 4 las siguientes definiciones:
    Entidad legal: una organización privada, entidad gubernamental, entidad comercial o entidad no comercial.
    Referencia de registro: un identificador único asignado a una entidad legal (persona jurídica).
    Esquema de registro: un esquema para asignar una referencia de registro que cumple con los requisitos identificados en el Apéndice H. “
  • Cambiar el título de la Sección 9.2 para indicar”Campos de Nombre Distinguido del Sujeto” (Subject Distinguished Name Fields).
  • Eliminar la Sección 9.2.2 y renumerar las secciones 9.2.3 a 9.2.8 como 9.2.2 a 9.2.7.
  • Insertar una nueva sección 9.2.8:
    “9.2.8. Campo identificador de organización del sujeto
    ** Campo de certificado **: organizationIdentifier (OID: 2.5.4.97)
    ** Requerido / Opcional **: Opcional
    ** Contenido **: Si está presente, este campo DEBE contener una referencia de registro para una entidad legal asignada de acuerdo con el Esquema de registro identificado.
    El organizationIdentifier DEBE estar codificado como PrintableString o UTF8String (ver RFC 5280).
    El Esquema de Registro DEBE identificarse utilizando la siguiente estructura en el orden presentado:
    * Identificador de esquema de registro de 3 caracteres;
    * Se utilizará el código de país ISO 3166 de 2 caracteres para la nación en la que opera el Esquema de Registro, o si el esquema se opera globalmente, se utilizará el código ISO 3166 “XG”
    * Para el identificador del Esquema de Registro NTR, si es requerido bajo la Sección 9.2.4, un identificador ISO 3166-2 de dos caracteres para la subdivisión (estado o provincia) de la nación en la que opera el Esquema de Registro, precedido por el signo más “+” ( 0x2B (ASCII), U + 002B (UTF-8));
    * un guión (signo menos) “-” (0x2D (ASCII), U + 002D (UTF-8));
    * Referencia de registro asignada de acuerdo con el Esquema de Registro identificado.Nota: las Referencias de Registro PUEDEN contener guiones, pero los Esquemas de Registro, los códigos de país ISO 3166 y los identificadores ISO 3166-2 no PUEDEN contenerlos. Por lo tanto, si aparece más de un guión en la estructura, el guión más a la izquierda es un separador, y los guiones restantes forman parte de la Referencia de Registro.Como en la sección 9.2.4, la información de ubicación especificada DEBE coincidir con el alcance del registro al que se hace referencia.Ejemplos:
    * NTRGB-12345678 (esquema NTR, Gran Bretaña, cuyo identificador único a nivel de país es 12345678)
    * NTRUS + CA-12345678 (Esquema NTR, Estados Unidos – California, cuyo identificador único a nivel estatal es 12345678)
    * VATDE-123456789 (Esquema de IVA o CIF, Alemania, cuyo Identificador único a nivel de país es 12345678)
    * PSDBE-NBB-1234.567.890 (Esquema de PSD2, Bélgica, con identificador de la NCA (National Competent Authority) por sus siglas NBB, y con identificador único del sujeto asignado por la NCA formado por la secuencia 1234.567.890)

    Los esquemas de registro enumerados en el Apéndice H se reconocen actualmente como válidos bajo estas pautas (“Guidelines”).

    La CA DEBE:
    1. confirmar que la organización representada por la Referencia de Registro es la misma que la organización nombrada en el campo de organización como se especifica en la Sección 9.2.1 dentro del contexto de la jurisdicción del sujeto según se especifica en la Sección 9.2.4;
    2. Verificar además que la Referencia de registro coincida con otra información verificada de acuerdo con la sección 11;
    3. Tomar las medidas adecuadas para desambiguar entre diferentes organizaciones como se describe en el Apéndice H para cada Esquema de Registro;
    4. Aplicar las reglas de validación relevantes al Esquema de Registro como se especifica en el Apéndice H. “

  • Insertar nueva sección 9.8 (renumerar las siguientes secciones según sea necesario):
    9.8. Extensiones de Certificado
    Las extensiones enumeradas en la Sección 9.8 se recomiendan para la máxima interoperabilidad entre los certificados y los navegadores / aplicaciones, pero no son obligatorias en las CA, excepto cuando se indica como “Requerido”. Las CA pueden usar otras extensiones que no están enumeradas en esta Sección 9.8, pero se les recomienda que propongan su inclusión en esta sección de vez en cuando para ayudar a aumentar la estandarización de la extensión en toda la industria.Si una CA incluye una extensión en un certificado que tiene un campo de Certificado que se menciona en esta Sección 9.8, la CA debe seguir el formato especificado en esa subsección. Sin embargo, ninguna extensión o formato de extensión será obligatorio en una CA a menos que se indique específicamente como “Requerido” en la subsección que describe la extensión.9.8.1. Extensión del nombre alternativo del sujeto (Subject Alternative Name Extension)
    ** Campo del certificado: ** _subjectAltName: dNSName_
    ** Requerido / Opcional: ** Requerido
    ** Contenido: ** Esta extensión DEBE contener uno o más nombres de dominio de host que sean propiedad o estén controlados por el sujeto y que estén asociados con el servidor del sujeto. Dicho servidor PUEDE ser propiedad y operado por el Sujeto u otra entidad (por ejemplo, un servicio de alojamiento). Los certificados comodín no están permitidos para los certificados EV.9.8.2. Campo de identificador de organización del foro de CA / navegador
    ** Nombre de la extensión **: _cabfOrganizationIdentifier_ (OID: 2.23.140.3.1)
    ** OID detallado **: {joint-iso-itu-t (2) international-Organizations (23) ca-browser-forum (140) extensiones de certificado (3) cabf-organization-identifier (1)}
    ** Requerido / Opcional **: Opcional (pero ver más abajo)
    ** Contenido **: Si el asunto: organizationIdentifier está presente, este campo DEBE estar presente.

    A partir del 31 de enero de 2020, si está presente el campo sujeto: organizaciónIdentificador, este campo DEBE estar presente.
    Si está presente, este campo DEBE contener una Referencia de Registro para una entidad legal asignada de acuerdo con el esquema de registro identificado.

    El esquema de registro DEBE estar codificado como se describe en la siguiente gramática ASN.1:

    id-CABFOrganizationIdentifier OBJECT IDENTIFIER ::= 
    { joint-iso-itu-t(2) international-organizations(23) 
    ca-browser-forum(140) certificate-extensions(3) 
    cabf-organization-identifier(1) }
    
    ext-CABFOrganizationIdentifier EXTENSION ::= 
    { SYNTAX CABFOrganizationIdentifier IDENTIFIED BY 
    id-CABFOrganizationIdentifier }
    
    CABFOrganizationIdentifier ::= SEQUENCE {
    
    registrationSchemeIdentifier   PrintableString (SIZE(3)),
    
    registrationCountry            PrintableString (SIZE(2)),
    
    registrationStateOrProvince    [0] IMPLICIT PrintableString OPTIONAL (SIZE(0..128)),
    
    registrationReference          UTF8String
    
    }
    

    donde están los subcampos y tienen los mismos significados y restricciones descritos en la Sección 9.2.8. La CA DEBE validar el contenido utilizando los requisitos de la Sección 9.2.8 “.

  • Añadir nuevo Apéndice H – Esquemas de registro
    “Los siguientes esquemas de registro se reconocen actualmente como válidos según estas pautas:** NTR **: La información incluida en este campo será la misma que se guardó en el campo Número de registro del sujeto como se especifica en 9.2.5 y el código de país utilizado en el identificador del esquema de registro coincidirá con el de la jurisdicción del sujeto según se especifica en la Sección 9.2.4.
    Cuando la Jurisdicción de constitución de la entidad o el Campo de Registro en 9.2.4 incluya más que el código del país, la información de localidad adicional se incluirá como se especifica en las secciones 9.2.8 y / o 9.8.1.** IVA **: Referencia asignada por las autoridades fiscales nacionales a una entidad jurídica. Esta información se validará utilizando la información provista por la autoridad fiscal nacional contra la organización identificada por el campo Nombre de la organización del sujeto (ver 9.2.1) y el campo del número de registro del sujeto (ver 9.2.5) dentro del contexto de la jurisdicción del sujeto según se especifica en la Sección 9.2.4.

    ** PSD **: Número de autorización especificado en ETSI TS 119 495, cláusula 4.4, asignado a un proveedor de servicios de pago y que contiene la información especificada en ETSI TS 119 495 cláusula 5.2.1. Esta información SE DEBE obtener directamente del registro de la autoridad nacional competente para servicios de pago o de una fuente de información aprobada por una agencia gubernamental, organismo regulador o legislación para este propósito. Esta información DEBE validarse comparándola directa o indirectamente (por ejemplo, haciendo coincidir un número de registro único global) con la organización identificada por el campo Nombre de la organización del sujeto (ver 9.2.1) y el Campo del número de registro del sujeto (ver 9.2.5). ) dentro del contexto de la jurisdicción del sujeto según se especifica en la Sección 9.2.4. La dirección indicada de la organización combinada con el nombre de la organización NO SERÁ la única información utilizada para desambiguar la organización “.

Invitación abierta – Grupo de Trabajo de AMETIC – Buenas prácticas en el campo de la video-identificación y el video onboarding


El próximo lunes 12 de noviembre se celebrará a las 12:00 una reunión en AMETIC para constituir un Grupo de Trabajo de Identidad Digital que yo presido y que excepcionalmente está abierto a entidades que no sean miembros de AMETIC.

El objetivo del grupo es elaborar un documento titulado provisionalmente “Guidelines o buenas prácticas en el campo de la video-identificación y el video onboarding” orientado a prestadores de servicios de certificación en el marco del EIDAS y a entidades financieras y otras de los ámbitos FinTech e Insurtech que vean útil contar con un procedimiento consensuado que refleje las mejores prácticas en identificación remota de usuarios, alineadas con la normativa de Prevención de Blanqueo de Capitales y Financiación del Terrorismo.

En el Grupo de Trabajo de Identidad Digital de AMETIC se compartirá la información pública difundida en el marco de las actividades del Grupo de Expertos de la Comisión Europea sobre técnicas de “Conoce a tu Cliente”, del que formo parte y del que se puede ver más información en este enlace:

Este grupo de expertos europeo ha tenido varias reuniones los pasados meses (9 de abril y 10 de julio) y un Taller (Workshop with providers of remote on-boarding solutions) el 28 de septiembre. La tercera reunión formal del grupo tiene lugar mañana 9 de noviembre en Bruselas, por lo que en la reunión del lunes 12 de noviembre podremos trabajar con la información más reciente en lo que se refiere a los avances en Europa.

  El objetivo de este artículo es invitar a las entidades interesadas a participar en este Grupo de Trabajo. Si lees este artículo y piensas que alguien pueda estar interesado, házselo llegar. Esta invitación se puede hacer extensiva a otras personas y entidades.

Para confirmar la asistencia, llamar lo antes posible a AMETIC (Madrid: 915 90 23 00, Barcelona: 93 241 80 60).

La dirección de AMETIC es:

  • Principe de Vergara, 74, 4ª planta – 28006 Madrid.

Para los que os vaya mejor Barcelona:

  • Avda. Sarriá, 28, 1º- 1ª – 08029 Barcelona.

Ambas sedes están conectadas por un sistema de videoconferencia

Empresas españolas con soluciones de Videonboarding e Identificación remota


Estoy recopilando información de empresas que ofrecen soluciones de identificación a distancia y “video onboarding”, y ya he identificado unas cuantas:

  • Lleidanet – eKYC Onboarding
  • Deloitte – OBA (Onboarding App)
  • Ecertic – KYDC (Know Your Digital Customer)
  • Electronic Identification (electronicID) – VideoID
  • ICAR vision (Mitek) – IDMobile
  • Branddocs  – TrustCloud VídeoConferencia

En estos momentos el interés por este tema es superior porque participo en el Grupo de Expertos de la Comisión Europea sobre técnicas de “Conoce a tu Cliente”, y las empresas identificadas con posibilidad de prestar estos servicios se incluirán en un informe disponible para la Comisión Europea y para las entidades participantes en los trabajos.

Así que aprovecho este articulo para pedir a quienes conozcan entidades que prestan estos servicios o los incorporan en sus estrategias (como las entidades financieras) que me hagan llegar la información suficiente para identificarlas.

 

Directiva PSD2 y certificados #eIdAS de Proveedores de Servicios de Pago


Ya se han tratado en este blog algunos aspectos relevantes sobre la Directiva (UE) 2015/2366 sobre servicios de pago en el mercado interior, también conocida como Directiva PSD2 (Segunda Directiva de Servicios de Pago).

En uno de los artículos del blog, de marzo de 2017 dedicado al Borrador Final de los Estándares Técnicos Regulatorios  (Final Draft Regulatory Technical Standards) y #eIdAS me atreví a vaticinar  como serían los perfiles de los certificados cualificados de los PISP (Servicios de iniciación de pagos) y de los AISP (Servicios de información sobre cuentas), y en especial la asignación del número identificativo al que se refiere la norma EN 319 412.

En la actualidad ya se ha publicado una norma técnica en estado de borrador que aterriza los conceptos necesarios para emitir los certificados cualificados a las Fintech que operen en el contexto de la PSD2. Se trata de la norma TS 119 495 titulada en inglés:

Sector Specific Requirements; Qualified Certificate Profiles and TSP Policy Requirements under the payment services Directive (EU) 2015/2366

Y unos pocos Prestadores de Servicios Electrónicos de Confianza están considerando su emisión.

La Segunda Directiva de Servicios de Pago favorecerá el crecimiento del mercado europeo de pagos electrónicos y armonizará el marco legislativo europeo aún fragmentado, tras la publicación de diferentes normas emitidas por cada Estado miembro en la transposición de la Primera Directiva de Servicios de Pago (Directiva 2007/64 / CE), que conlleva riesgos potenciales para la seguridad de los pagos y para la protección de los consumidores.

En el despliegue armonizado de la Segunda Directiva, los servicios de confianza definidos por el Reglamento UE 910/2014 (EIDAS)  no han recibido suficiente atención.

Uno de los aspectos clave de la Directiva PSD2 es la identificación electrónica confiable de los actores involucrados en una transacción de pago electrónico. En este marco regulatorio se ha definido por la Autoridad Bancaria Europea (EBA) un reglamento técnico específico que hace necesaria la “Autenticación fuerte del cliente” (SCA, Strong Customer Authentication) del pagador, que debe identificarse de manera confiable. Para este requisito, todos los proveedores de servicios de pago (PISP y AISP) deben acceder a las cuentas de pago o ejecutar órdenes de pago solo después de una autenticación fuerte del cliente en base a técnicas de doble factor de autenticación (2FA). 

Esta medida ha tenido una fría acogida por parte de los proveedores de servicios de pago que la ven como una amenaza para la experiencia de usuario del ordenante de pagos, frente a variantes que simplifican la interfaz añadiendo un simple botón de  “pago con un  clic” y la mínima fricción en la autenticación.

Aunque volveré sobre el tema de la autenticación de usuarios, hoy quería tratar sobre la identificación de los Prestadores de Servicios de Iniciación de Pagos y de Información sobre cuentas, para actualizar mi sugerencia de 2017 con lo que finalmente se ha plasmado en la norma de ETSI:

El atributo organizationIdentifier contendrá la información de identificación de la entidad  utilizando la siguiente estructura:

  • “PSD” como referencia de tipo de identidad de persona jurídica de 3 caracteres;
  • código de país de 2 caracteres ISO 3166 que representa el país del organismo supervisor;
  • guión-signo menos “-” (0x2D (ASCII), U + 002D (UTF-8)); y
  • Identificador de organismo supervisor de 2-8 caracteres (mayúscula A-Z solamente, sin separador)
  • guión-signo menos “-” (0x2D (ASCII), U + 002D (UTF-8)); y
  • Identificador de PSP (número de autorización según lo especificado por el organismo supervisor).

EJEMPLO: El identificador de organización “PSDES-BDE-0182” significa un certificado emitido a un PSP para el que el número de entidad es 0182, otorgada por el Banco de España. España (el identificador después del segundo guión lo establece el sistema de numeración español).

Monedas virtuales – Directrices para un enfoque basado en riesgo (documento del GAFI de 2015)


El Grupo de Acción Financiera Internacional (GAFI) emitió el informe Virtual Currencies Key
Definitions and Potential AML/CFT Risks, (Monedas Virtuales – Definiciones Clave y Riesgos Potenciales de Blanqueo de capitales y financiación del terrorismo), en junio de 2014 (Informe de junio de 2014 de Monedas Virtuales).

En los últimos años, las monedas virtuales (MV) han surgido y atraído inversión en infraestructura de pagos basado en los protocolos de software. Estos mecanismos de pagos intentan proporcionar un nuevo método para la transmisión de valor a través del internet.

El GAFI reconoce la innovación financiera que estas iniciativas pueden suponer. Al mismo tiempo, los productos de pago y servicios de MV (VCPPS por sus siglas en inglés) presentan riesgos de lavado de activos y financiación del terrorismo (LA/FT) y otros riesgos de delitos que deben ser identificados y mitigados.

Consecuentemente, el Grupo de Acción Financiera Internacional (GAFI) ha emitido en 2015 un nuevo informe “Guidance for a guidance for a risk-based approach to virtual currencies” (en español “Directrices para un enfoque basado en riesgo para monedas virtuales

Estas Directrices se centran en la aplicación de un enfoque basado en riesgo a los riesgos de LA/FT asociados con VCPPS y no en otros tipos de productos financieros de MV, tales como productos de valores de MV o de futuros. En consecuencia, las Directrices han adoptado el término productos de pagos y servicios de MV (VCPPS), en vez de productos y servicios de MV (VCPS), donde la discusión se limita a esquemas de pagos de MV.

El desarrollo de VCPPS y las interacciones de los VCPPS con otros Nuevos de Productos y
Servicios de Pago (NPPS por sus siglas en inglés) e incluso con servicios de banca tradicional, dan lugar a la necesidad de estas Directrices para proteger la integridad del sistema financiero global.

Estas Directrices independientes se basan en el citado informe de junio de 2014 de MV y en la
matriz de riesgo y las mejores prácticas del informe de Guidance for a Risk-Based Approach to Prepaid Cards, Mobile Payments and Internet Based Payment Services (Directrices para un Enfoque basado en Riesgo a las Tarjetas de Prepago, Pagos Móviles y Servicios de Pago en Internet) (Informe de NPPS de junio de 2013).

Estas Directrices forman parte de un enfoque gradual adoptado por el GAFI. El foco de estas
Directrices es sobre los puntos de intersección que proporcionan fuentes al sistema financiero
regulado, especialmente casas de cambio de moneda virtual convertible. El GAFI continuará
monitoreando los acontecimientos en los VCPPS y los emergentes riesgos y factores atenuantes.

Conforme avance el conocimiento de la tecnología y el uso de VCPPS, las Directrices se actualizarán para incluir, en su caso, mejores prácticas que emergen para abordar las cuestiones reglamentarias que surjan en relación con los riesgos de LA/FT asociadas a VCPPS. Cuestiones relacionadas con por ejemplo las transferencias dentro de las redes descentralizadas de MV convertibles que no implican actividades de intercambio, tales como transferencias de persona a persona involucrando “wallet providers” (servidores de proveedores de carteras) y pagos de gran valor de MV, que no están abordados por estas Directrices pueden ser considerados a largo plazo.

Hablando de pagos móviles en ElevenPaths Talks


11paths-julianinzaQuiero agradecer a Jorge Rivera y Pablo San Emeterio su invitación a participar en esta charla de ElevenPaths Talks sobre medios de pago móviles “PinPay y seguridad en micro pagos

¿Qué son los micro pagos? ¿Cómo afecta a la seguridad del proceso de pago? Nuestros CSAs Jorge Rivera y Pablo San Emeterio junto a un invitado especial resuelven tus dudas. ¡Aprende con nuestros expertos!

Recordando viejos tiempos en Mobipay, hablando de perfeccionamiento de contratos, identificación, EIDAS, Confianza Digital, PSD2.

Reflexionando sobre nuevos medios de pago basados en móvil, NFC, tarjetas, TPV,
protocolo MST de Samsung Pay para simular banda magnética con móviles concretos que soporten la tecnología. Consenso, Bizum,

Este es el video:

CIO Magazine identifica a Lleida.net como una de las Fintech más disruptivas del mundo


Lleidanet, que cotiza en el MAB (Mercado Alternativo Bursátil) es importante para el sector de los Prestadores de Servicios Electrónicos de Confianza porque hace visible para los inversores a todo un sector, cuya actividad es, a veces, difícil de explicar, por la complejidad legal y tecnológica de sus funciones.

Y es conocido el lema de que “no se debe invertir en algo que no se entiende”.

Esta visibilidad de todo un sector se ha hecho más patente gracias a la aparición de Lleidanet en el prestigioso medio especializado en ejecutivos y tecnologías de la información CIO. CIO es una publicación mensual dirigida a los Chief Information Officer (máximos responsables de informática de las empresas) fundada en 1987 en Massachusetts. Ofrece información especializada en tecnologías emergentes, productos, industria e investigaciones, tendencias, regulación e implicaciones sobre la tecnología.

Esta revista electrónica destaca a Lleida.net como una de las Fintech (empresas del sector de tecnologías financieras) a seguir durante 2017. La publicación escoge 20 empresas participantes en el Finovate Conference, un evento que muestra las últimas tendencias y acoge las empresas más inspiradoras del sector Fintech.

CIO indica que hay que seguir de cerca las actividades de Lleida.net. La empresa dirigida por Sisco Sapena ya está bien situada en España prestando, sobre todo, servicios de notificación fehaciente por SMS, actividad en la que fue pionera.

Es proveedora de entidades financieras y de telecomunicaciones y tiene el doble rol de operadora de telecomunicaciones y de prestador de servicios electrónicos de confianza.

Artículo:

Fresh fintech companies to watch in 2017
The 2017 Finovate Conference showcased some of the best and most advanced innovations in financial technology

(…)

Lleida.net

Remember the name Lleida.net. This electronic communications 
Company  is on fire, having obtained 10 new patents in the first quarter of the year.

Sisco Sapena, Lleida.net’s chief executive officer told me how today’s retailers (think Nordstrom Trunk Club), utility companies and telcos are becoming banks, but often doing so without the necessary infrastructure or expertise. Lleida.net offers a platform as a service (PaaS) focused on electronic notification and electronic contracting services, SMS solutions, and data validation, combining ease of use with legal validity.

With Lleida.net acting as a trusted third party, all communication sent through its systems can be used as documentary evidence for legal purposes. The company is listed on the Spanish Alternative Stock Market and boasts big-name clients, such as the Zurich Insurance Group and Colombia’s postal service, to name a few.

(…)