Archivo de la categoría: Medios de Pago

De las tablillas cuneiformes al Cartulario: historia de la contabilidad y origen de las RJT

Deja un comentario

Llevamos más de cinco mil años intentando resolver el mismo problema: dejar constancia fiable de quién tiene qué, quién debe qué y en qué orden ocurrieron las cosas. Las tablillas de arcilla de Mesopotamia, los libros de los mercaderes venecianos, las tarjetas de pago y lo que hoy llamamos blockchain son respuestas sucesivas a esa necesidad.

En este artículo recorro esa historia para defender una idea que ya he planteado otras veces: quien sabe un poco de contabilidad entiende enseguida que lo que estas tecnologías replican es un libro diario (journal), no un libro mayor (ledger). Y que buena parte de lo que se atribuye a blockchain puede conseguirse combinando firma electrónica y un registro fehaciente, también en un servidor centralizado.

Fichas, bullas y tablillas: contar ovejas en arcilla

La escritura nació, en buena medida, para llevar las cuentas. Según la tesis de la arqueóloga Denise Schmandt-Besserat, desde el VIII milenio a. C. se usaban en Oriente Próximo pequeñas fichas de arcilla (tokens) de distintas formas: cada forma representaba un tipo de bien (una oveja, una medida de grano, una jarra de aceite) y cada ficha, una unidad.

Hacia el 3500 a. C. aparece una innovación notable: las fichas de una operación se guardaban dentro de una bulla, una esfera hueca de arcilla que se sellaba. Para saber qué contenía sin romperla, se imprimían las fichas en su superficie antes de cerrarla. Era ya un mecanismo de integridad: el contenido sellado podía cotejarse con su «resumen» exterior, y cualquier manipulación exigía romper el sello.

Con el tiempo sobraron las fichas y bastaron las marcas: así surgieron las tablillas protocuneiformes de Uruk (hacia 3300-3000 a. C.), de contenido mayoritariamente administrativo. Un pastor que recibía un rebaño del templo quedaba anotado con el número de ovejas, cabras y corderos a su cargo, y después se le exigía cuenta de las crías, la lana y las bajas. En la época de Ur III (hacia 2100-2000 a. C.), el gran centro ganadero de Puzrish-Dagan (Drehem) dejó decenas de miles de tablillas con entradas y salidas diarias de animales, con su fecha y el funcionario responsable.

Ahí están ya los ingredientes que reaparecerán en toda esta historia: un asiento por cada hecho, una fecha, un responsable, un sello que impide la alteración y un archivo que conserva la prueba.

De Roma a Venecia: los precursores de la partida doble

Durante siglos la contabilidad fue de partida simple: una lista de cobros y pagos, o de deudas a favor y en contra. Los romanos distinguían ya entre los apuntes provisionales del día (adversaria) y el libro definitivo de ingresos y gastos (codex accepti et expensi). Es un primer esbozo de la separación entre lo que se anota cronológicamente y lo que se ordena para su consulta.

El salto llega con el comercio italiano de la Baja Edad Media. Ayudaron dos cosas: la difusión de los números indoarábigos, impulsada por el Liber Abaci de Fibonacci (1202), y unas sociedades mercantiles con socios, corresponsales y crédito a distancia. Llevar las cuentas con números romanos era penoso; sumar columnas con cifras posicionales, no.

Los primeros rastros de doble anotación aparecen en la Toscana y en Liguria:

  • Florencia: las cuentas de la compañía de Rinieri Fini y sus hermanos (1296) ya registran cada operación en dos lados.
  • Provenza: los libros de la compañía Farolfi (1299-1300), florentina, muestran un sistema muy completo.
  • Génova: los libros de los massari (tesoreros) del Comune de 1340 se consideran el primer ejemplo plenamente desarrollado de partida doble.

Venecia perfeccionó el método y le dio nombre: alla veneziana. Los libros de los hermanos Soranzo (1406-1434) ya presentan la tríada de borrador, diario y mayor que luego se describirá por escrito. En 1458 el mercader ragusino Benedetto Cotrugli explicó la partida doble en Della mercatura e del mercante perfetto, aunque su obra no se imprimió hasta 1573. El método estaba en uso; faltaba un libro impreso que lo enseñase.

Luca Pacioli y la formalización (1494)

Ese libro llegó en 1494. El fraile franciscano y matemático Luca Pacioli, amigo de Leonardo da Vinci, publicó en Venecia la Summa de arithmetica, geometria, proportioni et proportionalità, impresa por Paganino Paganini. Uno de sus tratados, Particularis de computis et scripturis, describe el método veneciano con detalle práctico.

Pacioli no inventó la partida doble, pero la sistematizó y, gracias a la imprenta, la difundió por Europa. Describe tres libros:

  1. El memorial (memoriale): borrador donde se anota todo tal como ocurre.
  2. El diario (giornale): los asientos en orden cronológico, ya depurados, con su cargo y su descargo.
  3. El mayor (quaderno): las mismas partidas reordenadas por cuentas, con un índice alfabético.

Recomienda además cerrar el ejercicio comprobando que la suma de lo cargado coincide con la de lo abonado. Si no coincide, hay un error que buscar.

En España la partida doble llegó pronto a la ley. La Pragmática de Cigales de 1549 obligó a mercaderes y banqueros a llevar sus cuentas en libro de caja con su manual «por debe y ha de haber». El primer tratado en castellano fue el Libro de caxa y manual de cuentas de mercaderes de Bartolomé Salvador de Solórzano (1590).

El principio de la partida doble: una suma de comprobación de cinco siglos

La regla es sencilla: todo hecho económico se anota dos veces, en el debe de una o varias cuentas y en el haber de otras, por el mismo importe. No hay deudor sin acreedor: lo que entra en una cuenta sale de otra.

Si un ganadero compra 100 ovejas a 50 € cada una y paga por transferencia, el asiento es este:

N.ºFechaCuentaDebe (€)Haber (€)
13 de marzoGanado (activo)5.000
13 de marzoBancos (activo)5.000

Como cada asiento cuadra, la suma de todos los cargos del ejercicio debe ser igual a la de todos los abonos. Si no lo es, hay un error de suma, de transcripción o de traspaso. Esa igualdad es un control de integridad incorporado al propio método: no hace falta otra fuente para saber que algo falla.

Es el mismo principio que siglos después usará la informática: añadir redundancia calculada para detectar alteraciones. Son de la misma familia la prueba del nueve (ya conocida por los maestros de ábaco), los dígitos de control de los números de cuenta (el IBAN usa un módulo 97), las sumas de paridad y los CRC (Cyclic Redundancy Check), propuestos por W. Wesley Peterson en 1961 para detectar errores de transmisión.

También comparten limitaciones. El cuadre contable no detecta un asiento omitido entero, un importe erróneo anotado igual en ambos lados ni errores que se compensan. Un CRC detecta errores accidentales, pero cualquiera puede recalcularlo tras modificar los datos. Contra la manipulación intencionada hacen falta otras herramientas: funciones hash criptográficas, sellos de tiempo y firma electrónica. A ellas llegaremos.

Libro diario, libro mayor y los estados que se derivan de ellos

Conviene fijar bien esta distinción, porque es la clave del resto del artículo:

  • El libro diario (journal) registra los asientos en orden cronológico, numerados y fechados, tal como suceden. Es la fuente primaria. Un asiento ya anotado no se borra: si hay un error, se corrige con un contraasiento posterior.
  • El libro mayor (ledger) reordena esas mismas partidas por cuentas (Caja, Bancos, Clientes, Ganado…), normalmente en forma de «cuentas en T» con su debe y su haber. Se obtiene «pasando» los asientos del diario. No añade información: es una vista derivada que permite conocer el saldo de cada cuenta.

El legislador español lo tiene claro. El Código de Comercio (arts. 25 a 28) exige una contabilidad ordenada que permita «un seguimiento cronológico de todas sus operaciones» y obliga a llevar el libro diario y el de inventarios y cuentas anuales, que se legalizan en el Registro Mercantil. El mayor no es obligatorio: siempre puede reconstruirse desde el diario. Lo que tiene valor probatorio es el orden cronológico.

A partir del diario y del mayor se elaboran los estados contables:

EstadoQué muestraPara qué sirve
Balance de comprobación de sumas y saldosSumas del debe y del haber, y saldo, de cada cuentaVerificar que cargos y abonos cuadran antes del cierre
Balance (de situación)Activo, pasivo y patrimonio neto en una fechaSaber qué se tiene y qué se debe: activo = pasivo + patrimonio neto
Cuenta de pérdidas y gananciasIngresos y gastos del ejercicioConocer el resultado (beneficio o pérdida)
Estado de flujos de efectivoCobros y pagos por actividades de explotación, inversión y financiaciónEntender la liquidez, que no coincide con el resultado

La informática no cambió el método, pero sí su manejo. VisiCalc (1979), de Dan Bricklin y Bob Frankston, llevó a la pantalla la hoja de cálculo cuadriculada de los contables. Después llegaron Lotus 1-2-3 (1983) y Excel (1985). Con ellas se popularizaron las previsiones de tesorería y los modelos de flujos de caja, que permiten simular escenarios antes de que ocurran.

Antes de 2009: del cheque al Hashcash

Si la contabilidad resolvió cómo anotar el valor, los medios de pago intentaron resolver cómo moverlo sin mover monedas. Antes de que apareciera Bitcoin, el siglo XX ya había probado casi todas las piezas:

  • Tarjetas de pago. Diners Club lanzó en 1950 la primera tarjeta de uso general. Le siguieron BankAmericard (1958), germen de Visa, y Master Charge (1966), luego Mastercard. Detrás de cada pago hay un apunte en los libros del emisor y del adquirente, conciliados por la red.
  • Transferencias. Las redes interbancarias sustituyeron el envío físico de órdenes. SWIFT se fundó en 1973 y empezó a operar en 1977. En Europa, la transferencia SEPA arrancó en 2008.
  • Adeudos (domiciliaciones). El acreedor inicia el cobro con autorización previa del deudor, que conserva el derecho a devolverlo. Los adeudos directos SEPA llegaron en noviembre de 2009.
  • Dinero electrónico criptográfico. David Chaum propuso en 1982 las firmas ciegas para pagos no rastreables y fundó DigiCash en 1989. Le siguieron e-gold (1996), b-money de Wei Dai (1998) y bit gold de Nick Szabo.
  • Sellado de tiempo encadenado. Stuart Haber y W. Scott Stornetta publicaron en 1991 cómo encadenar documentos mediante hash para que no pudieran antedatarse. Tres de las ocho referencias del artículo de Bitcoin son suyas.

En España también hubo precursores. En 2002, con el impulso del Ministerio de Ciencia y Tecnología, se desarrolló el proyecto PISTA – FIRMA – Títulos cambiarios electrónicos, en el que participé desde FESTE, donde era director general, junto a Banc Sabadell y Roca Junyent, entre otros. Su objetivo era gestionar letras de cambio desmaterializadas y endosables. Para ello combinaba firma electrónica, una entidad de timbrado y una Fuente de Verdad centralizada que impedía que un mismo título se endosara o cobrara dos veces. A eso lo llamábamos «unicidad de fin»: es el mismo problema que Bitcoin resolvería después con el nombre de «doble gasto». Lo conté en «Antecedentes de Blockchain en España».

La pieza más curiosa nació contra el correo basura. En 1992 Cynthia Dwork y Moni Naor propusieron «cobrar» a cada remitente un pequeño esfuerzo de cálculo. En 1997 Adam Back presentó Hashcash: para enviar un correo había que encontrar un valor cuyo hash empezase por un número determinado de ceros. Costaba una fracción de segundo a un remitente legítimo, pero hacía carísimo enviar millones de mensajes. Hal Finney lo reutilizó en 2004 en sus Reusable Proofs of Work.

Satoshi Nakamoto convirtió esa «prueba de trabajo» en el mecanismo para decidir quién añade el siguiente bloque. El artículo de Bitcoin se publicó el 31 de octubre de 2008 y el bloque génesis se minó el 3 de enero de 2009. Casi nada era nuevo: lo nuevo fue la combinación.

¿DLT o RJT? Lo que se replica es un diario

A estas tecnologías se las llamó pronto DLT (Distributed Ledger Technology), y así las nombra la normativa europea. El Reglamento eIDAS 2 regula en su artículo 45 terdecies los registros electrónicos cualificados. La traducción oficial al español habla de libros mayores electrónicos, y así se titula también el Reglamento de Ejecución (UE) 2025/2531, que fija sus normas de referencia. Expliqué ese marco en la entrada sobre la conservación cualificada y los servicios cualificados con orden cronológico (qDLT).

Con la contabilidad en la mano, el nombre chirría. Una cadena de bloques es una sucesión de asientos en orden cronológico, cada uno enlazado con el anterior mediante su hash, que no se borran y solo se corrigen con anotaciones posteriores. Eso es exactamente un libro diario. El «mayor» (los saldos de cada dirección, el conjunto de salidas no gastadas de Bitcoin o el estado de un contrato inteligente) no se transmite: cada nodo lo calcula recorriendo el diario, igual que un contable pasa los asientos a las cuentas.

Por eso propuse hace años hablar de RJT (Replicated Journal Technology), como expliqué en «RJT – Replicated Journal Technologies. Cómo llamar a Blockchain» y en «No es DLT: es RJT, o mejor, simplemente Blockchain» (2019). Las dos palabras importan:

  • Journal (diario), porque lo que se conserva y se protege es el orden cronológico de los hechos, que es lo que tiene valor probatorio.
  • Replicated (replicado), mejor que «distribuido», porque cada nodo tiene una copia completa e idéntica. No hay fragmentos repartidos, sino réplicas que deben coincidir.

En aquel artículo de 2019 señalé que «DLT» solo encaja con los usos que registran valores contabilizables y deja fuera piezas esenciales como la firma electrónica. Concluí entonces que, para nombrar el conjunto, lo más práctico era seguir diciendo simplemente blockchain. Hoy no lo tengo tan claro: sigue faltando un término que agrupe la firma electrónica y el registro donde residen la autenticidad y la historia de los documentos, sin atarlo a una cadena de bloques. Más abajo propongo uno.

Seguiré usando DLT y «libro mayor electrónico» cuando me refiera a la norma, porque son sus términos oficiales. Pero quien haya llevado alguna vez un diario y un mayor entenderá por qué RJT describe mejor lo que hace la tecnología.

Blockchain son dos técnicas que van juntas

Si se quita el ruido, bajo la etiqueta blockchain hay dos técnicas que se necesitan mutuamente.

1. La firma electrónica. Cada transacción va firmada con la clave privada de quien la ordena (en Bitcoin, con ECDSA sobre la curva secp256k1). La firma acredita quién autoriza el movimiento y garantiza que el contenido no se ha alterado. Es la misma función que cumple la firma del comerciante en su libro, o la del otorgante ante notario.

2. Una fuente de verdad. Firmar no basta: hay que saber qué operación vale cuando dos se contradicen (el «doble gasto», o la «unicidad de fin» de PISTA) y en qué orden ocurrieron las cosas. Hace falta un registro único y ordenado que todos acepten como referencia.

Los notarios resolvieron este segundo problema hace mucho con el protocolo notarial. El notario conserva el documento matriz (la escritura original firmada), lo incorpora a su protocolo en orden cronológico y con numeración correlativa, y entrega copias a los interesados. La copia hace fe porque puede cotejarse con la matriz, que no sale de la notaría. Si dos copias discrepan, manda la matriz.

Una cadena de bloques hace lo mismo sin una notaría: el mecanismo de consenso (la prueba de trabajo, en Bitcoin) decide cuál es la «matriz» que todos los nodos replican. Ese consenso es caro y lento precisamente porque sustituye a un tercero de confianza que no existe.

Cuando ese tercero sí existe, como un prestador cualificado de servicios de confianza supervisado, la fuente de verdad puede mantenerse en un servidor centralizado. Se combinan firmas y sellos electrónicos, sellos de tiempo y encadenamiento de hash, y se obtienen las mismas garantías de integridad y orden con mucho menos coste. He tratado su aplicación a la Justicia en Judiciary Blockchain, por ejemplo en «eIDAS 2.0: el reconocimiento europeo de los registros electrónicos con orden cronológico» y en «Unicidad de fin en el documento electrónico».

Una propuesta: SJT, Signed Journal Technology

Si lo esencial son esas dos piezas, el nombre debería decirlas. Propongo SJT (Signed Journal Technology, tecnología de diario de asientos firmados): un diario que conserva la historia de los hechos en orden cronológico y actúa como fuente de verdad, y una firma electrónica que acredita la autenticidad e integridad de cada asiento: lo firma su autor, y el operador lo sella en el tiempo y lo encadena con los anteriores. El término no exige bloques, ni réplicas, ni un mecanismo de consenso concreto.

Con él, los términos dejan de competir y se ordenan:

  • SJT: firma electrónica + diario que actúa como fuente de verdad.
    • SJT centralizada: un prestador de confianza mantiene la fuente de verdad. Es el caso de PISTA en 2002 o del Cartulario hoy.
    • SJT replicada, que es lo que he llamado RJT: la fuente de verdad se decide por consenso entre nodos con copias idénticas.
      • Blockchain: una RJT concreta, que agrupa los asientos en bloques encadenados por hash.

En un texto jurídico, el equivalente en español podría ser diario fehaciente, que recoge a la vez la autenticidad, el orden y el valor probatorio.

Un diario fehaciente en un servidor centralizado: el Cartulario de EADTrust

En la Edad Media, monasterios, catedrales y concejos copiaban en un cartulario los privilegios, donaciones y títulos de propiedad que acreditaban sus derechos. Era su libro de la verdad. En EADTrust tomamos ese nombre para un servicio que aplica las ideas de este artículo sin necesidad de una cadena de bloques pública.

El Cartulario trata el archivo como un registro, no como un simple depósito de ficheros. Anota la titularidad de cada documento, su estado y sus relaciones con otros. Lo diseñamos hace años partiendo de las premisas de la gestión de valores mediante anotaciones en cuenta, con tres funcionalidades en mente:

  • Transferibilidad (endosabilidad): registrar el cambio de titular de un derecho documentado, como ya se hacía con los títulos cambiarios endosables del proyecto PISTA.
  • Obliterabilidad (cancelabilidad): dejar constancia de que un derecho se ha consumido o cancelado, para que no pueda usarse dos veces.
  • Completitud: mantener unidos el documento, sus anexos y sus versiones.

Cada solicitud de archivo recibe un sello de tiempo con precisión de 1 milisegundo, lo que refuerza la garantía del orden cronológico. Es, en términos contables, un libro diario fehaciente: firma electrónica para la autoría e integridad, y una fuente de verdad centralizada, operada por un prestador de servicios de confianza, para el orden y el estado.

Hoy el Cartulario se presta como servicio de confianza no cualificado. El Reglamento de Ejecución (UE) 2025/2531 ya fija las normas de referencia de los libros mayores electrónicos cualificados, tanto centralizados como distribuidos. Podrá presentarse como cualificado cuando supere la correspondiente evaluación de conformidad eIDAS.

Conclusión

De la bulla sellada de Uruk al bloque encadenado por hash hay cinco mil años, pero el problema es el mismo: anotar hechos en orden, impedir que se alteren y poder comprobarlo. La partida doble aportó un control de integridad aritmético. La criptografía aportó la firma y el hash. Y lo que la tecnología replica entre nodos es, ante todo, un diario. Por eso sigo pensando que RJT es mejor nombre que DLT. Y, para el conjunto de firma y diario, propongo SJT: el valor no está en que el registro sea distribuido, sino en que sea un diario firmado y fehaciente.

Si quiere saber más sobre el Cartulario o los servicios de confianza de EADTrust, puede escribir a info@eadtrust.com, llamar al 91 716 05 55 o visitar www.eadtrust.eu.

Artículos relacionados

Congreso Internacional «Desafíos pendientes en la digitalización de los mercados financieros (del 4 al 6 de marzo de 2025)

Deja un comentario

El Congreso Internacional «Desafíos pendientes en la digitalización de los mercados financieros» tendrá lugar los días 4, 5 y 6 de marzo de 2025 en el Salón de Grados de la Facultad de Derecho Universidad Complutense de Madrid.

Mi presentación, titulada «Seguridad Jurídica Preventiva Digital. Los servicios cualificados de confianza europeos EIDAS y EIDAS2” tendrá lugar el 4 de marzo.

Organizado en el marco del proyecto de investigación La digitalización de los mercados financieros (análisis jurídico) – PID2020-113447RB-I00, IP es la prof. Isabel Fernández Torres.

  • Dir. Isabel Fernández Torres, Catedrática (Ac.), UCM
  • Dir. Adjunta: Luz María García, UCM

Acceso libre hasta completar aforo.

Martes, 4 de marzo de 2025


9:00 Inauguración de las Jornadas
9:15 Ponencia inaugural: Miguel Ángel Fernández Ordoñez, ex – gobernador del Banco
de España


METAVERSO, IA, MACHINE LEARNING Y SU IMPACTO EN EL MUNDO JURÍDICO

9:45 Conferencia: “IA en el mercado financiero”, Isabel Fernández Torres, Universidad
Complutense
10: 45 Conferencia: “AI Regulation”, T. Bonneau, Univ. Paris II Panthéon-Assas


11:00 Mesa redonda. Modera Maite Martínez Martínez, Universidad Complutense

  • Almudena de la Mata (Blockchain Intellingence Law Institute): “Confluencia de IA y Blockchain en el Metaverso y los nuevos servicios financieros”
  • Julián Inza (Presidente EAD Trust): “Seguridad Jurídica Preventiva Digital. Los servicios cualificados de confianza europeos EIDAS y EIDAS2”
  • Noemí Brito (KPMG): “Ética Digital e IA Confiable”
  • Pedro Portellano (Universidad Autónoma de Madrid): “Decisiones financieras, inteligencia artificial y Business Judgment Rule”

12:00 Pausa-Café

DATOS

12:30 Conferencia: “Minería de datos”, Begoña González Otero, Max Planck for
innovation and competition (Munich).


13.00 Mesa redonda. Modera Antonio Alonso Bartol Bustos, Universidad Complutense

  • Luis Felipe López (UDIMA): “Protección de Datos”
  • Cristina Timón (Universidad de Murcia): “Identidad Digital”
  • Julio V. González (Universidad Complutense): “Transferencia internacional de datos”
  • Julia Suderow (Universidad de Deusto): “Big data: nuevos modelos y mala regulación”

14:00 Comida

15.30 Mesa redonda. INATBA
16.30 Comunicaciones


Miércoles, 5 de marzo de 2025


MERCADOS DE CAPITAL DIGITALES

9.00 Conferencia. Montserrat Martínez Parera, Vicepresidenta de la Comisión Nacional del Mercado de Valores
9.30 Conferencia, Francesca Romana Medda, “Sandboxes”, University College of London

10:15 Mesa redonda. Modera Javier Juste Mencía, Universidad Complutense

  • Nuria Fernández (Universidad de Alicante): “Protección al inversor”
  • Luz María García (Universidad Complutense): “Abuso de mercado y descentralización”
  • Konstantinos Sergakis (Glasgow University): “Democratizing Finance via AI: Investor Protection and Investor Engagement”
  • Juan Ignacio Peinado Gracia (Universidad de Málaga): “Sostenibilidad y digitalización”

11:45 Pausa/café

PRESENTE Y FUTURO DE LOS CRIPTOACTIVOS

12:15 Conferencia. Carmen Pastor, Universidad de Alicante

12.45 Mesa redonda. Modera Javier Megías López, Universidad Complutense

  • Cristina Guerrero (Universidad Complutense): “Taxonomía”
  • Alfredo Muñoz (Universidad Complutense): “Colocación y venta de tokens”
  • Emilio Díaz Ruíz (Universidad Complutense): “Transparencia en la promoción y colocación”
  • Rebeca Herrero Morant (Universidad de Zaragoza): “Algunos problemas jurídicos de los security tokens”

14.15 Comida

EURODIGITAL, TRIBUTACION Y BLANQUEO DE CAPITALES

16.00 Conferencia: Francisco Javier Priego, Secretario General del Banco de España

16.30 Conferencia: Joachim Wüermeling, former member of the Executive Committee Bundesbank, Partner Allen y Board Member Blockchain Intelligence

17.00 Mesa redonda. Modera: José Luis Colino Mediavilla, Universidad Complutense

  • José María López (Universidad de Málaga): “Proveedores de servicios de pago”
  • Xavier Codina (CUNEF): “Blanqueo de capitales”
  • Pablo Sanz Bayón (ICADE): “Comparativa CBDCs”
  • Rosa Galán (Universidad Complutense): “Tributación” DEFI, DAOS, P2P

18.15 Modera: Eva Recamán Graña, Universidad Complutense

  • Alfonso Martínez Echevarría (CEU): “Tokens de gobernanza”
  • Sagrario Navarro (UCLM): “DAOS”
  • Ana Muñoz (URJC): “DEFI”
  • Fernando Carbajo (Universidad de Salamanca): “NFT”

Jueves, 6 de marzo de 2025

9.00 DIGITALIZACION Y REGISTROS

NUEVOS DESAFIOS EN EL DERECHO BANCARIO

10.30 Conferencia: Rosa María Barresi, University of Florence

11.00 Conferencia: Alicia Muñoz Lombardía, Banco Santander

11:30 Pausa Café

12.00 Mesa redonda. Modera José Carlos González Vázquez, Universidad Complutense

  • Alberto Ruiz Ojeda (Universidad de Málaga): “Resolución y digitalización”
  • Mª Ángeles Alcalá (Universidad de Castilla la Mancha): “Digitalización y Buen Gobierno Corporativo”
  • Francisco Uría (KPMG): “PSD3”
  • Silvia Madrid (Unicredit): “Compliance”
  • Sofia País (Universidad Católica de Porto): “Prácticas anticompetitivas en el sector Bancario”

13.30 PONENCIA DE CLAUSURA: Montserrat Martínez Parera, Vicepresidenta de la
CNMV

Orden en el caos: Evaluación de conformidad en entornos complejos (en el Panel: Estándares, Identidad Digital y Servicios de Pago)

Deja un comentario

En el contexto del III Congreso Internacional «Presente y futuro de la regulación de los criptoactivos en la Unión Europea» organizado por LegalCripto by BAES y la Universidad de Alicante los días 13, 14 y 15 de diciembre de 2023, que ya comenté quisiera llamar la atención sobre el Cuarto Panel que tiene lugar el viernes 15 de diciembre de 2023 a las 10:00.

10:00   Cuarto Panel: Estándares, Identidad Digital y Servicios de Pago

Presenta y modera: Dra. Mª José Vañó Vañó, Profesora Titular de Derecho Mercantil en la Universidad de Valencia e investigadora en LegalCripto

  • PSD3 en el contexto de los criptoactivos con función de pago — Dra. Lucía Alvarado Herrera, Profesora Titular de Derecho Mercantil en la Universidad Pablo de Olavide de Sevilla y colaboradora en LegalCripto.
  • Orden en el caos: Evaluación de conformidad en entornos complejos — Dña. Ainhoa Inza Blasco, Chief Executive Officer del Trust Conformity Assessment Body (tCAB).
  • Marcos de referencia en seguridad como camino a seguir — D. Pablo López, Jefe del Área de Normativa y Servicios de Ciberseguridad del Centro Criptológico Nacional (CCN).
  • La futura regulación europea sobre identidad digital y su impacto en los medios de pago — Dña. Mª Cristina Timón López, Investigadora doctoral en la Universidad de Murcia, consultora de pagos digitales para la firma holandesa Explicit Selection y colaboradora en iDerTec y LegalCripto.

Presente y futuro de la regulación de los criptoactivos en la Unión Europea

1 respuesta

Es motivo de satisfacción compartir con vosotros mi participación en el III Congreso Internacional «Presente y futuro de la regulación de los criptoactivos en la Unión Europea» organizado por LegalCripto by BAES y la Universidad de Alicante los días 13, 14 y 15 de diciembre de 2023.

Mi intervención es el día 13 de diciembre a las 16:30 en el Primer Panel

16:30   Primer Panel: ¿Qué cabe esperar en Metaverse, Artificial Intelligence, Replicated Journal Technology, Large Language Models, Quantum Computing, Post Quantum cryptography, Central Bank Digital Currency, Citizen Digital Identity and Wallets?

Presenta y modera: Dra. Carmen Pastor Sempere, Profesora Titular de Derecho Mercantil en la Universidad de Alicante e Investigadora Principal de LegalCripto.

  • Tecnologías con futuro y su impacto en el Derecho — D. Julián Inza, Presidente de EAD Trust y Director del Laboratorio de Confianza Digital del Observatorio Legaltech & Newlaw Garrigues-ICADE.
  • Inteligencia Artificial, Descentralización y Web 4.0 — Dr. Víctor Rodríguez Doncel, Profesor Asociado de Inteligencia Artificial en la Universidad Politécnica de Madrid.
  • Panorama legislativo complejo en la UE sobre IA y la regulación sectorial — Dra. Yolanda Bustos Moreno, Profesora Titular de Derecho Civil en la Universidad de Alicante.

El Congreso se enmarca en el Programa Prometeo 2023, Proyecto CIPROM/2022/26

Laboratorio de Confianza Digital ICADE Garrigues

2 respuestas

La Universidad Pontificia Comillas y el despacho de abogados Garrigues, firmaron un convenio para crear el Observatorio ‘Legaltech’, Garrigues-ICADE.

El Observatorio, depende de la Facultad de Derecho (Comillas ICADE), a través del Centro de Innovación del Derecho (CID-ICADE).

En la organización del Observatorio destacan Fernando Vives (Presidente), Iñigo Navarro (Codirector), Moisés Menéndez (Codirector), Ofelia Tejerina (Coordinadora) y Hugo Alonso (Gestión de Proyectos).

Formando parte del Observatorio se han definido ya varios laboratorios:

Ahora se crea el Laboratorio de Confianza Digital ICADE Garrigues y he sido nombrado Director del Laboratorio, lo que para mi es un gran honor.

Aunque todavía estoy recopilando información para incorporarla a la página web del Laboratorio que se creará en el sitio de la Universidad de Comillas quisiera comentar que en este momento estamos dando prioridad al análisis del futuro Reglamento EIDAS2 y a la formulación de la Cartera IDUE que se espera que en unos dos años esté disponible para todos los ciudadanos europeos.

Hemos creado un Enlace de invitación al Canal de Whatsapp del Laboratorio de Confianza Digital en el que comentaremos novedades y al que se pueden conectar las personas interesadas.

Posteriormente organizaremos eventos presenciales con diversos ponentes en las instalaciones de la Universidad.

Y dado que soy de Pamplona y hoy es 6 de julio, pongo esta fotico del chupinazo que se ha disparado a las 12 de la mañana desde el balcón del ayuntamiento para celebrar que hoy comienzan las fiestas de San Fermín.

Normativa relativa a la gestión de entidades de pago y entidades de dinero electrónico

Deja un comentario

El dia 4 de diciembre de 2020 se ha publicado en el BOE la Circular 5/2020, de 25 de noviembre, del Banco de España, a entidades de pago y a entidades de dinero electrónico, sobre normas de información financiera pública y reservada, y modelos de estados financieros, y que modifica la Circular 6/2001, de 29 de octubre, sobre titulares de establecimientos de cambio de moneda, y la Circular 4/2017, de 27 de noviembre, a entidades de crédito, sobre normas de información financiera pública y reservada, y modelos de estados financieros.

Entre otras, esta circular se relaciona con las siguientes normas:

  • Orden ECE/1263/2019, de 26 de diciembre, sobre transparencia de las condiciones y requisitos de información aplicables a los servicios de pago y por la que se modifica la Orden ECO/734/2004, de 11 de marzo, sobre los departamentos y servicios de atención al cliente y el defensor del cliente de las entidades financieras, y la Orden EHA/2899/2011, de 28 de octubre, de transparencia y protección del cliente de servicios bancarios.
  • Real Decreto 736/2019, de 20 de diciembre, de régimen jurídico de los servicios de pago y de las entidades de pago y por el que se modifican el Real Decreto 778/2012, de 4 de mayo, de régimen jurídico de las entidades de dinero electrónico, y el Real Decreto 84/2015, de 13 de febrero, por el que se desarrolla la Ley 10/2014, de 26 de junio, de ordenación, supervisión y solvencia de entidades de crédito.
  • Real Decreto-ley 19/2018, de 23 de noviembre, de servicios de pago y otras medidas urgentes en materia financiera.
  • Real Decreto 84/2015, de 13 de febrero, por el que se desarrolla la Ley 10/2014, de 26 de junio, de ordenación, supervisión y solvencia de entidades de crédito.
  • Real Decreto-ley 6/2020, de 10 de marzo, por el que se adoptan determinadas medidas urgentes en el ámbito económico y para la protección de la salud pública.
  • Real Decreto 309/2020, de 11 de febrero, sobre el régimen jurídico de los establecimientos financieros de crédito y por el que se modifica el Reglamento del Registro Mercantil, aprobado por el Real Decreto 1784/1996, de 19 de julio, y el Real Decreto 84/2015, de 13 de febrero, por el que se desarrolla la Ley 10/2014, de 26 de junio, de ordenación, supervisión y solvencia de entidades de crédito
  • Directiva (UE) 2015/2366 del Parlamento Europeo y del Consejo de 25 de noviembre de 2015 sobre servicios de pago en el mercado interior y por la que se modifican las Directivas 2002/65/CE, 2009/110/CE y 2013/36/UE y el Reglamento (UE) no 1093/2010 y se deroga la Directiva 2007/64/CE (Texto pertinente a efectos del EEE)

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

Deja un comentario

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

Contacte con EADTrust para obtener Certificados Cualificados PSD2 , llame al 917160555.

Resuelto uno de los frenos a los certificados cualificados de PSD2

1 respuesta

EIDAS-CAB-forumEl CAB Forum ha aprobado una modificación del documento «Extended Validation Guidelines» para permitir incluir guiones en el campo organizationIdentifier (OID 2.5.4.97) de los certificados EV (Extended Validation), 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 compatibles con EV 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 Cualificado 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, VAT, 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 organizationIdentifier 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 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 explícitam 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 «.

Magnetic Secure Transmission (MST)

2 respuestas

La Transmisión Magnética Segura (en inglés Magnetic Secure Transmission, MST) es una tecnología adoptada en ciertos teléfonos móviles como algunos SAMSUNG que emite una señal magnética que imita la que generaría una banda magnética de una tarjeta de pago tradicional al deslizarse sobre el cabezal lector del TPV.

Cuando se usan medios de pago configurados en teléfonos móviles con tecnología MST, el teléfono envía una señal magnética al lector de tarjetas del terminal de pago lo que simula el deslizamiento de la banda magnética de una tarjeta en el cabezal de lectura.

De esta forma se pueden usar Terminales Punto de Venta (en inglés, Point Of Sale, POS) antiguos y modernos (ya que todos los TPV soportan la tecnología de banda magnética aunque puedan dar soporte a otras, como las tarjetas chip o NFC) y no hace falta actualizar el hardware o el software del terminal con tecnologías específicas.

La tecnología MST es válida para casi todos los terminales de pago del munco equipados con  lector de tarjetas, si bien algunos terminales de pago pueden requerir actualizaciones de software, para dar soporte a la funcionalidad más avanzada de la tecnología.

Para usarlo, hay que seleccionar la tarjeta a emular en la aplicación de pagos del teléfono móvil y acercar el móvil a unos 2 centímetros del punto en el que el TPV equipa el cabezal de lectura (hacia la mitad del recorrido de la ranura por la que se desliza habitualmente la tarjeta de crédito).

La información de la transacción y los datos de identificación del pago se mantienen en secreto, securizados con el uso de tokenización.

El uso de la tecnología MST es más seguro que el de una tarjeta de pago tradicional y de un nivel de seguridad equivalente a la de una operación de pago con tecnología de comunicaciones de campo cercano (en inglés, Near Field Communication, NFC).

Hablando de pagos móviles en ElevenPaths Talks

Deja un comentario

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: