Archivo de la categoría: SEPA

Sandbox regulatorio: Una oportunidad de negocio


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

Hay que inscribirse en este enlace.

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

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

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

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

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

Plazo de devolución de los adeudos SEPA


sepa-imageHace algún tiempo explicaba como preparar los mandatos SEPA, en particular como determinar el Identificador del acreedor y también como establecer el Código BIC o SWIFT.

También he hablado sobre la diferencia entre las modalidades de adeudo SEPA «Core» y B2B y sobre la forma de calcular el código IBAN de las cuentas bancarias.

Hoy toca hablar de los plazos de devolución. Es decir, de cuanto tiempo tiene el deudor para solicitar al banco la retrocesión del apunte de adeudo.

Son plazos diferentes según se trate de órdenes SEPA «Core» (o «basicas») o de órdenes SEPA «B2B» (o «entre empresas»)

Core Básico

Se destina principalmente a operaciones con particulares pero puede ser también ser utilizada para adeudos con empresas. El acreedor utiliza el formato definido en el Cuaderno-19-14-XML Esquema Básico para enviarlo a su entidad. Previamente debe existir una orden de domiciliación firmada o aceptada por el deudor para la emisión de adeudos.

Plazo devolución

  • Hasta 5 días por cualquier motivo
  • Hasta 8 semanas por orden del cliente
  • 13 meses para pagos no autorizados

B2B Entre empresas

Se destina principalmente a operaciones con empresas pero puede ser también ser utilizada para adeudos con autónomos.  El acreedor utiliza el formato definido en el Cuaderno-19-44-XML Esquema B2B para enviarlo a su entidad. Previamente debe existir una orden de domiciliación firmada o aceptada por el deudor para la emisión de adeudos.

Plazo devolución

2 días hábiles, sin posibilidad de cancelación por el deudor una vez efectuado el cargo en cuenta. No obstante requiere que el deudor apruebe cada adeudo con su entidad, lo que genera muchas incidencias si no se realiza en plazo.

Mandatos digitales. Facilitando los adeudos SEPA


El 14 de febrero de 2014 entró en vigor en la eurozona el marco de servicios “SEPA” (Single Euro Payments Area) que impactaba en las transferencias, los adeudos por domiciliación y el uso de tarjetas, para igualar su uso intraeuropeo a lo que venía siendo la oprativa nacional de esos servicios lo que significaba un cambio en los usos y prácticas adoptados hasta ese momento.

Fue una época en la que las entidades financieras enviaban cartas para informar a sus clientes de lo que esto significaba. Los cambios que tendrían que gestionar los deudores y los acreedores, quienes realizan el proceso de iniciar los adeudos, por ejemplo, y quienes aceptan recibir esos adeudos.

Uno de los cambios consistía en que nuestra cuenta corriente cambiaba añadiendo un prefijo al código CCC (Código Cuenta Cliente) para formar el código IBAN (International Bank Account Number), otro, en que las transferencias nacionales e internacionales ya eran transferencias SEPA y otro que los adeudos necesitaban contar con autorización expresa.

Ya he comentado algunos de los aspectos relativos a SEPA en este blog, en estos artículos.

A pesar de los avances, hay que dar un nuevo paso en el aspecto de los adeudos por domiciliaciones. Al principio. las organizaciones que realizan el cobro de sus servicios a través de domiciliación bancaria enviaron millones de cartas, para recoger la autorización firmada en papel en papel y poder acreditar el consentimiento de sus deudores. A partir de ese momento “las órdenes de domiciliación” de toda la vida se llamarían “mandato”.

Este era un primer paso para la zona única de pagos en euros, imprescindible en la transformación digital en la que estamos inmersos y la creación del “Mercado único digital europeo”.

El siguiente paso es  migrar del soporte papel a la prestación del consentimiento digital y adoptar los mandatos electrónicos.

El Comité Nacional de Pagos (CNP) es un foro de encuentro entre los diferentes agentes económicos con intereses en el mercado de los servicios de pago en España. Presidido por el Banco de España, se encuentra integrado por representantes tanto del lado de la oferta como la demanda del mercado de pagos minoristas.

Su área de actividad es el conjunto de asuntos relacionados con el mercado de pagos minorista, teniendo como objeto contribuir al desarrollo de unos servicios, instrumentos e infraestructuras de pago de bajo valor que hagan que la economía nacional esté mejor integrada en Europa y que sea más competitiva, eficiente y útil para todas las partes.

Uno de los asuntos tratados es el de la validez de los mandatos digitales para la emisión de adeudos directos SEPA (SDD – SEPA Direct Debit).

El Comité ha recopilado las variantes de firma electrónica y de mecanismos digitales de prueba de la prestación del consentimiento en los mandatos para que sirva de orientación a las entidades. Por supuesto, la principal norma que determina el marco legal es el Reglamento UE 910/2014 (EIDAS) que regula la firma electrónica y los servicios de confianza en Europa, y deroga la Directiva  1999/93 CE. Esta norma dió lugar a la Ley 59/2003 que ya no resulta de aplicación salvos en aspectos que no contemple el Reglamento EIDAS.

Una de las variantes aceptadas es la que se deriva del uso de plataformas gestionadas por terceros, como por ejemplo EADTRUST (European Agency of Digital Trust), que recogen las evidencias electrónicas con mecanismos como las notificaciones fehacientes (Noticeman) basadas en mail y SMS.

Contacte con EADTRUST en el +34 91 7160555 si quiere saber como integrar la recogida de mandatos digitales con sus aplicaciones para gestionar mejor los adeudos directos SEPA.

 

¿Cómo llevamos la adaptación a SEPA?


Aunque el 1 de febrero de 2014 era la fecha inicialmente prevista para eliminar las modalidades no-SEPA de transferencias y domiciliaciones bancarias que se realicen en España y el resto de los países miembros de la Unión Europea, lo cierto es que el cambio no está siendo tan radical como parecía, empezando por el retraso de algunas entidades financieras de proporcionar los servicios adecuados para la transición a los estándares y normas SEPA (Single Euro Payments Area). Los principales beneficios que se esperan de la implantación de una Zona Única de Pagos en Euros son:

  • La desaparición de barreras para la ejecución de pagos internacionales, especialmente a nivel de costes.
  • La posibilidad de utilizar una sola cuenta bancaria para operaciones en euros dentro de la zona SEPA, sin requerir abrir cuentas en varios paises.
  • Una cierta mayor protección para los usuarios de servicios de pago.
  • El uso de estándares comunes, que permite mejoras de eficiencia en los procesos de ejecución de pagos, cuando se trata de operaciones internacionales o de empresas multinacionales..

Los principales aspectos a tener en cuenta para la adaptación, son los siguientes:

  • El IBAN será el identificador único de cualquier cuenta de pago en SEPA, reemplazando a los actuales identificadores de cuenta nacionales (el CCC en el caso español). Muchas entidades ofrecen servicios gratuitos de conversión para cuentas españolas
  • Nuevo formato de intercambio de información entre las Empresas y las Entidades bancarias.
  • Adeudos Directos SEPA en fichero electrónico, orientado a particulares– Esquema básico (core): Serie normas y procedimientos bancarios Cuaderno Nº 19-14.
  • Adeudos Directos SEPA en fichero electrónico, orientado a empresas – Esquema B2B (Business to Business): Serie normas y procedimientos bancarios Cuaderno Nº 19-44.

Puede ampliar información sobre la Diferencias entre la modalidad B2B y la básica del mandato SEPA de adeudo por domiciliaciones Creación de un mandato. El mandato es el medio por el que el deudor autoriza y consiente al acreedor a:

  • Iniciar los cobros mediante el cargo en la cuenta indicada por el deudor.
  • Autorizar a la entidad del deudor a cargar en su cuenta los adeudos presentados al cobro por la entidad bancaria del acreedor.

El mandato, que tendrá una referencia única, debe estar suscrito por el deudor como titular de la cuenta de cargo o persona en disposición de poder otorgado por éste, antes de iniciar el cobro de los adeudos. Puede ampliar información sobre

Las adaptaciones tendrán unos costes asociados para las entidades bancarias y para las empresas de difícil recuperación, ya que no producirán cambios significativos en el aumento de los negocios ni el incremento de los márgenes de beneficio. Por ello, el mejor enfoque es aprovechar la necesidad de cambio para acometer algún otro cambio técnico y organizativo que sí se traduzca en reducción de costes o en mejora de posición competitiva.

Entre los ejemplos de posibles soluciones, cabe la posibilidad de implantar sistemas de firma digitalizada o de firma vocal para la creación de los mandatos: Una de las características de la normativa SEPA es que, a partir del 1 de febrero de 2014, es obligatorio para las empresas recabar la firma de los clientes que contraten un servicio que será cobrado a través de un adeudo bancario. Sin el consentimiento expreso del cliente con alguna modalidad de firma, manuscrita o electrónica, la empresa prestadora del servicio no podrá solicitar a ninguna entidad bancaria el cobro de sus recibos, o podrá ver como los recibos son devueltos por el acreedor. Existen diferentes posibilidades para la obtención de la firma de los clientes:

  • Mediante la firma del mandato en papel.
  • Mediante la firma del mandato por medios electrónicos, a través de Internet y/o dispositivos móviles.
  • Mediante firma mediante un sistema de confirmación por llamada telefónica que esté diseñado con las debidas garantías.

Por otra parte, SEPA establece que la información contenida en los mandatos, incluida las firmas, debe quedar almacenada en poder de la empresa acreedora mientras esté en vigor el periodo de reembolso, así como durante los plazos que establezca la Ley para la conservación de documentos una vez cancelado.

También puede ser una gran oportunidad para que las empresas comiencen la adaptación a la Ley 3/2014, de 27 de marzo, por la que se modifica el texto refundido de la Ley General para la Defensa de los Consumidores y Usuarios.  Ver más en este artículo sobre Firma vocal como soporte duradero para call centers

Diferencias entre la modalidad B2B y la básica del mandato SEPA de adeudo por domiciliaciones


Las principales diferencias entre la modalidad B2B y la básica del mandato SEPA son:

  • En el mandato B2B el deudor no tiene derecho a devolver una transacción autorizada, ya que se autoriza conforme lo notifica el banco.
  • El instrumento B2B requiere que las entidades de los deudores se aseguren de que las transacciones están autorizadas mediante verificación de la transacción y la información del mandato al deudor, normalmente por banca electrónica.
  • La entidad de crédito del deudor no puede ofrecer el instrumento B2B a un cliente deudor que tenga la consideración de «consumidor» según la normativa del país en el que la entidad del deudor presta los servicios de pago. Por la misma razón, un acreedor no puede presentar pagos vía el instrumento B2B a clientes que son consumidores.
  • En respuesta a las necesidades específicas de la comunidad empresarial, el instrumento B2B ofrece ciclos de cobro significativamente más cortos para la ejecución de los adeudos directos y restringe los plazos de devolución, pero requiere la aprobación una a una por el deudor.

Ya sabéis que en EADTrust estamos ayudando a las empresas a adaptarse a SEPA, con mecanismos como el sistema de notificaciones Noticeman, que permite obtener la conformidad del mandato por parte del deudor, con cursos y seminarios y con diversos artículos que explican como resolver los problemas asociados a los nuevos códigos:

Seminario: Adaptación a SEPA de los adeudos por domiciliaciones


El nuevo mandato SEPA sustituye las autorizaciones de domiciliación tradicionales y define varios campos diferentes, como el código de acreedor, el código SWIFT del banco del deudor o el IBAN. Para facilitar la transición que la implantación de este mandato implica, se realiza una jornada formativa organizada por Atenea Interactiva denominada «Adaptación a SEPA de los adeudos por domiciliaciones«, en la que se cubre exhaustivamente el mandato SEPA «core» y el mandato SEPA B2B para sustituir los adeudos por domiciliaciones.

Este curso sobre la adaptación a SEPA, obligatoria en febrero de 2014, se realizará el 17 de Diciembre de 2013.

Con el curso se proporcionan gratuitamente además una colección de herramientas, documentos y modelos en formatos editables para facilitar y automatizar la adaptación a SEPA, así como las explicaciones para utilizarlas. Accede al folleto del curso en este enlace.

La inscripción, por tan solo 199 € (los inscritos hasta el 12 de diciembre de 2013), en este enlace

Hoja excel para el cálculo del IBAN y el código de acreedor en SEPA


Estamos preparando un seminario para Atenea Interactiva, con las claves principales de lo que tienen que hacer las empresas para adaptarse a SEPA.

Esto implica valorar el esfuerzo de adaptación para pasar de los viejos formatos del CSB (Consejo Superior Bancario) a los nuevos de la AEB (Asociación Española de Banca) CECA y UNACC, con una fecha límite en mente: febreo de 2014.

Entre las adaptaciones más importantes y más complejas, está la que tiene que ver con con el mandato SEPA básico y el mandato SEPA B2B de lo que eran las domiciliaciones bancarias o adeudos directos.

Y tenemos una buena noticia, en el seminario entregaremos una hoja Excel con la herramienta de codificación y comprobación de código de IBAN (a partir del dato de CCC-Código Cuenta Cliente español) y de código de acreedor del mandato (a partir del NIF o CIF español), así como un modelo de mandato en Word, listo para poder hacer una fusión con datos de nuestros clientes de modo que podamos preparar con facilidad los mandatos.

También entregaremos el listado de códigos SWIFT de los bancos españoles, con lo que no necesitaremos que estos datos nos los proporcionen los clientes.

Y por último entregaremos códigos de prueba de Noticeman  para poder usar dicho sistema de notificación fehaciente, y dejar constancia de la aceptación del mandato mediante la técnica de correo electrónico certificado. Una de las formas más sencillas de conseguir la desmaterialización del mandato sin tener que gestionar firmas manuscritas.

Como preparar los mandatos SEPA – Identificador del acreedor


Uno de los datos importantes del mandato SEPA es el «identificador del acreedor» o «creditor Identifier» que tiene una regla de construcción un poco enrevesada en cuanto al cálculo del código de control.

En Españal formato es este: ESZZXXXAAAAAAAAA, siendo:

  • ES: código del país España según la norma ISO 3166
  • ZZ: dígitos de control (cuyo cálculo se explica a continuación)
  • XXX: sufijo (normalmente 000, pero el acreedor puede gestionar más de un canal de adeudos poniendo otros valores)
  • AAAAAAAAA: CIF del acreedor, frecuentemente una letra seguida de 8 cifras, sin espacios, guiones u otros símbolos.
Los dígitos de control se calculan en base al NIF, aplicando el modelo 97-10 (regla de cálculo definida en la norma ISO 7604 y ampliamente usada en la norma ISO 20022, UNIFI).
  • Tomamos posiciones de la 8 a la 15, es decir el CIF, añadiendo ES y 00
Por ejemplo, en el caso de EADTrust, B85626240ES00
  • Convertimos letras a números, considerando que la A es 10, la B es 11, … la E es 14, … la  S es 28, … hasta que la Z es 35.
Por ejemplo, en el caso de EADTrust, 1185626240142800
  • Aplicamos modelo 97-10 (dado un número, lo dividimos entre 97 y restamos a 98 el resto de la operación. Si se obtiene un único dígito, se completa con un cero a la izquierda)
Por ejemplo, en el caso de EADTrust, el resto de dividir 1185626240142800 entre 97 sale 21 y 98-21=77, por tanto el código completo:  ES77000B85626240