Archivo de la categoría: Banca

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

 

 

Certificados de prueba #eIdAS para #PSD2


Hace ya algún tiempo traté sobre los certificados que se podrían usar en el contexto de PSD2, en el artículo “Directiva PSD2 y certificados #eIdAS de Proveedores de Servicios de Pago

Todavía antes (en 2017) traté temas técnicos (algunos controvertidos) de PSD2 en el artículo “Segunda directiva de servicios de pago (PSD2) y Regulatory Technical Standards

PSD2-PI-AI-Card

Ahora ya hay más información y sabemos como se codificarán las Autoridades Nacionales Competentes en los certificados de los prestadores delos diferentes servicios definidos en PSD2:

i) Servicios de cuenta (PSP_AS) que proporcionan las entidades financieras actuales;
ii) Servicios de iniciación de pagos (PSP_PI) que proporcionarán nuevas entidades accediendo a las cuentas que sus clientes tienen en los proveedores de servicios de cuenta y ordenando transferencias en su nombre;
iii) Servicios de información de cuentas (PSP_AI) que proporcionarán nuevas entidades accediendo a las cuentas que sus clientes tienen en los proveedores de servicios de cuenta y recogiendo las transacciones de varias entidades para presentarlas al cliente de formas más interesantes o útiles;
iv) Servicios de expedición de instrumentos de pago basados en tarjetas (PSP_IC), para emisión de servicios equivalentes a tarjetas virtuales o adquirencia de transacciones de pago de tarjetas.

La lista de entidades es

Code Country Authority Title
AT-FMA Austria Austria Financial Market Authority
BE-NBB Belgium National Bank of Belgium
BG-BNB Bulgaria Bulgarian National Bank
HR-CNB Croatia Croatian National Bank
CY-CBC Cyprus Central Bank of Cyprus
CZ-CNB Czech Czech National Bank
DK-DFSA Denmark Danish Financial Supervisory Authority
EE-FI Estonia Estonia Financial Supervisory Authority
FI-FINFSA Finland Finnish Financial Supervisory Authority
FR-ACPR France Prudential Supervisory and Resolution Authority
DE-BAFIN Germany Federal Financial Supervisory Authority
GR-BOG Greece Bank of Greece
HU-CBH Hungary Central Bank of Hungary
IS-FME Iceland Financial Supervisory Authority
IE-CBI Ireland Central Bank of Ireland
IT-BI Italy Bank of Italy
LI-FMA Liechtenstein Financial Market Authority Liechtenstein
LV-FCMC Latvia Financial and Capital Markets Commission
LT-BL Lithuania Bank of Lithuania
LU-CSSF Luxembourg Commission for the Supervision of Financial Sector
NO-FSA Norway The Financial Supervisory Authority of Norway
MT-MFSA Malta Malta Financial Services Authority
NL-DNB Netherlands The Netherlands Bank
PL-PFSA Poland Polish Financial Supervision Authority
PT-BP Portugal Bank of Portugal
RO-NBR Romania National Bank of Romania
SK-NBS Slovakia National Bank of Slovakia
SI-BS Slovenia Bank of Slovenia
ES-BE Spain Bank of Spain
SE-FINA Sweden Swedish Financial Supervision Authority
GB-FCA United Kingdom Financial Conduct Authority

Las URLS de las NCA (National Competent Authorities) Autoridades Naciones Competentes se ven en la siguiente lista:

Country Competent authority
Austria Financial Market Authority
Belgium National Bank of Belgium
Bulgaria Bulgarian National Bank
Croatia Croatian National Bank for credit institutions and Croatian Financial Services Supervisory Agency for investment firms
Cyprus Central Bank of Cyprus
Czech Republic Czech National Bank
Denmark Finanstilsynet
ECB (SSM) European Central Bank (SSM)
Estonia Financial Supervision Authority
Finland Finanssivalvonta (Fin-FSA)
France Autorité de contrôle prudentiel et de Resolution
Germany BaFin and Bundesbank
Greece Bank of Greece
Hungary Central Bank of Hungary
Iceland Financial Supervisory Authority
Ireland Central Bank of Ireland
Italy Banca d’Italia
Latvia Financial and Capital Market Commission
Liechtenstein Financial Services Authority
Lithuania Bank of Lithuania
Luxembourg Commission de Surveillance du Secteur Financier
Malta Malta Financial Services Authority
Netherlands De Nederlandsche Bank
Poland Polish Financial Supervision Authority
Portugal Banco de Portugal
Romania National Bank of Romania
Slovakia National Bank of Slovakia
Slovenia Bank of Slovenia
Spain Banco de España
Sweden Finansinspektionen
UK Prudential Regulation Authority and Financial Conduct Authority

Con la novedad de que ya se pueden introducir guiones en el campo organizationIdentifier que mencioné en el artículo “Resuelto uno de los frenos a los certificados cualificados de PSD2” ya se pueden emitir certificados cualificados extended validation para las diferentes entidades que operan en el despliegue de PSD2.

Algunos Prestadores de Servicios de Certificación ya se están preparando para emitirlos (inicialmente, certificados de prueba) y en TCAB ya estamos listos para auditarlos. Llámenos al  91 388 0789

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 “.

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:

Final Draft Regulatory Technical Standards y #eIdAS


El artículo 25 del proyecto de norma técnica reguladora publicado por la EBA en cumplimiento del mandato de la Comisión Europea de desarrollo de la PSD2 (Segunda Directiva de Pagos) se refiere a los requisitos de identificación y el 29 al mecanismo específico de los certificados.

En este último artículo queda patente la importancia de los servicios de confianza definidos por el EIDAS (Reglamento UE 910/2014).

  1. Para el propósito de identificación, a que se refiere el artículo 21, apartado 1, letra a), los proveedores de servicios de pago  confiarán en certificados cualificados para generación de sellos electrónicos tal como se definen en el apartado 30 del artículo 3 del Reglamento (UE) n ° 910/2014 4 o en los certificados de autenticación de sitio webpara según se definen en el en el apartado 39 del artículo 3 de dicho Reglamento.
  2. A los efectos del presente Reglamento, el número de registro contemplado en la letra C del anexo III del Reglamento (UE) no 910/2014 se referirá al número de autorización correspondiente a los proveedores de servicios de pago que emiten instrumentos de pago basados en tarjetas (payment service provider issuing card-based payment instruments),  a los proveedores de servicios de información de cuenta (account information service provider) y a los proveedores de servicios de iniciación de pagos (payment initiation service provider), así como los prestadores de servicios
    de pagos de gestión de cuenta (account servicing payment service provider) que proporcionen dichos servicios, según consten  en el registro público del Estado miembro de origen del prestador, de conformidad con el artículo 14 de la Directiva (UE) 2015/2366 o según resulte de la notificación de cada autorización concedida al amparo del artículo 8 de la Directiva 2013/36 / EU de conformidad con el artículo 20 de dicha Directiva.
  3. A efectos del presente Reglamento, los certificados cualificados para generación de sellos electrónico  o para la autenticación del sitio web a que se refiere el párrafo 1 del presente artículo, deberán incluir varias menciones en lengua inglesa para reflejar los siguientes atributos específicos adicionales:
    (a) el papel del prestador de servicios de pago, que podrá ser uno o más  uno o más de los siguientes:  “account servicing payment service provider”; “payment initiation service provider”;  “account information service provider”;  “payment service provider issuing card-based payment instruments”, respectivamente “proveedor de servicios de pago de gestión de cuenta”, “proveedor de servicios de iniciación de pago”, “proveedor de servicio de información de cuenta” y “proveedor de servicios de pago que emite instrumentos de pago basados en tarjetas”.
    (b) la denominación de las autoridades competentes en las que el prestador de servicios está registrado.
    4. Los atributos mencionados en el apartado 3 no afectarán a la interoperabilidad y
    reconocimiento de certificados calificados para sellos electrónicos o autenticación de sitios web.

En el marco de #eIdAS es de aplicación el estándar EN 319 412 en sus partes 1, 3 y 4 (EN 319 412-1, EN 319 412-3 y EN 319 412-4) por lo que la mención del registro de entidades financieras correspondería a las siglas BA (Banking Authority).

eadt-logoPor ejemplo, el “serial number” del certificado cualificado del BBVA a los efectos de la autenticación como “Prestador de servicios de gestión de cuentas” en el marco de la segunda directiva de pagos (PSD2) debería identificarse con el valor  BA:ES0182

EADTrust ya está en condiciones de emitir certficados cualificados para prestadores de servicios amparados por la PSD2 y alineados con la versión publicada a finales de febrero de 2017 de los “Regulatory Technical Standards” de la European Banking Association.

Cambios en las domiciliaciones SEPA desde noviembre de 2016


En los dos últimos años, tanto las entidades financieras como las que giran adeudos por domiciliaciones a través de ellas, según la normativa “Cuaderno AEB 19 de recibos” (antiguo cuaderno CSB 19 o variantes modernas AEB 19.14 y AEB 19.44),  se  han ido adaptando a todos los cambios necesarios para cumplir con la normativa europea, de manera que todos los ficheros emitidos tuvieran el formato único europeo SEPA.

Actualmente en España existen dos modelos de cuadernos de adeudos SEPA que permiten presentarlos en plazos distintos, a elección del usuario y de la localización de la entidad de destino:

  • Esquema CORE: con plazos de 4 días si el adeudo es recurrente o último  y 7 días si el adeudo es el primero o único.
  • Esquema COR1: con plazos de 1 día antes de la fecha de vencimiento del recibo siempre que los adeudos sean nacionales.

A partir del 21 de noviembre de 2016, el esquema COR1 desapare en España y solamente se pueden enviar cuadernos en formato CORE.

Sin embargo, los plazos que tiene este esquema CORE a partir del cambio, son los mismos que el establecido para el COR1, es decir, todos los adeudos, sea cual sea su tipología se podrán presentar hasta un día antes de su fecha de vencimiento. Además ya no hace falta distinguir si el adeudo es el primero en caso de adeudo periódico o recurrente, sino que se delega a la entidad del deudor la operativa de identificar el primer adeudo en caso de este tipo de adeudos.

Por lo tanto, a partir de la fecha indicada sólo existirá un modelo de cuaderno 19, con todas las ventajas que supone el presentar cualquier tipo de adeudo hasta el día anterior a su vencimiento y que afectará por igual tanto al cuaderno tradicional (19.14) como al cuaderno de adeudos domiciliados orientados a empresas B2B (19.44).