Dirección general de Economía y Estadística

(1)

Aplicaciones técnicas de la Circular 1/2012, de 29 de febrero, sobre

normas para la comunicación por los proveedores de servicios de

pago de las transacciones económicas con el exterior

Departamento de Estadística

Dirección general de Economía y Estadística

(2)

(3)

ÍNDICE

1 Normas generales 3

1.1 Entidades obligadas a declarar 3

1.2 Presentación de la información 3

1.3 Presentación de la información a través de otra entidad 3

1.4 Plazo de presentación 3

1.5 Soportes telemáticos con errores 3

2 Especificaciones técnicas para el intercambio de información electrónica 7

2.1 Envío 7

2.2 Recepción 7

2.2.1 Estructura del archivo con el mensaje de respuesta 7

2.2.2 Ejemplos del archivo con el mensaje de respuesta 15

2.3 Conservación de los datos 16

3 Contenido de la información 19

3.1 Frecuencia y contenido de la información 19

3.2 Tipos de transacciones 19

3.3 Identificación de las transacciones 19

3.4 Rectificaciones 20

4 Especificación de las transacciones y variables 23

4.1 Especificación de los archivos con las transacciones 23

4.1.1 Información de cabecera del archivo (Cabecera) 23

4.1.2 Información del proveedor de servicios de pago declarante (InformeDeclarante) 24

4.1.3 Información de transacciones 24

4.1.4 Definición de las variables del esquema de información 31

5 Criterios de depuración de los archivos 39

(4)

5.1.1 Controles previos al envío 39

5.1.2 Descripción de la estructura y validaciones realizadas en el esquema XML “TransExtPSP.xsd” 39

5.1.3 Declaración XML 39

5.1.4 Elemento Raíz <Informe> 39

5.1.5 Elemento <Cabecera> 40 5.1.6 Elemento <InformeDeclarante> 40 5.1.7 Elemento <OperaEnPeriodo> 41 5.1.8 Elemento <TransaccionTipo1> 42 5.1.9 Elemento <TransaccionTipo2> 44 5.1.10Elemento <TransaccionTipo3> 45 5.1.11Elemento <RectifBajaPeriodoAnt> 46 5.1.12Elemento <RectifAltaPeriodoAnt> 47 5.1.13Elemento <ClienteResidente> 47 5.1.14Elemento <ClienteNoResidente> 47 5.1.15Elemento <CuentaClienteContrapartida> 48

5.2 Otras depuraciones no contempladas en el esquema XML 49

5.2.1 Depuraciones generales 49

5.2.2 Depuración de la cabecera 49

5.2.3 Depuración del informe del declarante 50

5.2.4 Depuración en el informe del declarante de las transacciones normales 50

5.2.5 Depuración en el informe del declarante de las transacciones de baja

53

5.2.6 Depuración en el informe del declarante de las transacciones de alta

54

6 Codificación de variables y atributos 57

6.1 Codificación de variable Categoría 57

6.2 Codificación de variable CodAduana 57

(5)

6.4 Codificación de la variable Moneda 58

6.5 Codificación de la variable PagoSEPA 62

6.6 Codificación de la variable País 62

6.7 Codificación de la variable Propósito 68

6.8 Codificación de la variable SistemaLiqComp 75

6.9 Codificación de la variable TipoOperación 75

Anejo a – Impreso para los proveedores de servicios de pago (PSP) declarantes de transacciones con el exterior 79

Anejo b – Modelo de carta a enviar por los proveedores de servicios de pago (PSP) remitentes cuando informen en nombre de un tercero declarante 80

Anejo c – Modelo de carta a enviar por aquellos proveedores de servicios de pago (PSP) que carezcan de la operativa sujeta a declaración 81

(6)

(7)

Apartado 1

(8)

(9)

DEPARTAMENTO DE ESTADÍSTICA – APLICACIONES TÉCNICAS DE LA CIRCULAR 1/2012 3

1 Normas generales

1.1 Entidades obligadas a declarar

En virtud de lo dispuesto en la Circular 1/2012 del Banco de España para los proveedores de servicios de pago (en adelante PSP) sobre normas para la comunicación al Banco de España de las transacciones económicas con el exterior, estas son de obligado cumplimiento para las entidades de esta naturaleza inscritas en los Registros Oficiales del Banco de España.

1.2 Presentación de la información

De acuerdo con lo dispuesto en la norma cuarta de la Circular 1/2012, del Banco de España, la información deberá presentarse por medios telemáticos, es decir, mediante el uso de redes de comunicación de datos.

Los datos relativos a un PSP y a un mes componen un "archivo lógico"; por tanto, no podrán incluirse en el mismo "archivo lógico" datos de distintos PSP, con la excepción que se contempla en el apartado 1.3 siguiente.

1.3 Presentación de la información a través de otra entidad

Excepcionalmente el Banco de España podrá autorizar a que se incluyan en un mismo soporte telemático los datos correspondientes a varios PSP. A este respecto habrá de tenerse en cuenta lo siguiente:

- Los PSP que realizan transacciones económicas con el exterior por cuenta de sus clientes y presentan esta información por medio de otro PSP (PSP remitente). En este caso, deberá figurar como PSP declarante el que ha efectuado la operación, y en ningún caso el remitente.

- El citado PSP remitente vendrá siempre identificado en el informe de cabecera al que se hace referencia en el apartado 4 de estas normas, y en concreto en la variable

PSPRemitente. Esta identificación se realizará, incluso en el caso de que en el archivo telemático no se incluyan datos de ese PSP.

1.4 Plazo de presentación

El plazo de presentación vencerá al término de los diez días hábiles siguientes a la fecha de las transacciones cuya información se comunica.

1.5 Soportes telemáticos con errores

El Banco de España, ante un soporte telemático con errores por no ajustarse a las características detalladas en el apartado 2 Especificaciones técnicas para el intercambio de información electrónica, en el apartado 4 Especificación de las transacciones y variables y en el apartado 5 Criterios de depuración de los archivos de estas normas, comunicará al PSP remitente los errores detectados para que, en su caso, proceda a la inmediata remisión de un nuevo soporte telemático debidamente rectificado.

(10)

4 DEPARTAMENTO DE ESTADÍSTICA - APLICACIONES TÉCNICAS DE LA CIRCULAR 1/2012

En los casos en que existan errores en alguno de los PSP autorizados por el Banco de España para que presenten su información junto con otros en un único soporte telemático, la rectificación a remitir será solamente la correspondiente a los PSP con errores.

(11)

Apartado 2

Especificaciones técnicas para el intercambio de información

electrónica

(12)

(13)

2 Especificaciones técnicas para el intercambio de información electrónica

La información se presentará por medios telemáticos, de acuerdo con las especificaciones y los procedimientos contenidos en el documento Normas de adhesión y de intercambio de información para DTE.

Se distinguen dos tipos de intercambio telemático de archivos:

- Envío: consiste en la transmisión de los archivos desde un PSP al departamento de Estadística del Banco de España.

- Recepción: consiste en la generación y transmisión automática de un archivo del departamento de Estadística del Banco de España al PSP.

2.1 Envío

Los proveedores de servicios de pago remitirán al departamento de Estadística del Banco de España los archivos en formato XML que deberán validarse con el Esquema XML proporcionado por este departamento.

De todos los canales disponibles para la conexión con el Banco de España, los admitidos actualmente para la transmisión de archivos referidos a la información del servicio DTE son: RedBdE-EDITRAN, Internet-ITW y SWIFT-FileAct.

La documentación detallada para cada uno de ellos se podrá consultar en los siguientes enlaces:

Trasmisión Ficheros por EDITRAN, la red del BdE y con Clave Pública (TF_REDBDE_EDITRAN)

Trasmisión Ficheros por ITW, INTERNET y con certificados electrónicos (TF_INTERNET_ITW)

Trasmisión Ficheros por File-Act, la red SWIFT y certificado de esta red privada (TF_SWIFT_FileAct)

2.2 Recepción

El departamento de Estadística del Banco de España remitirá por cada archivo recibido un mensaje informando al PSP remitente del resultado de la depuración de los datos de cada PSP declarante, con el detalle, en su caso, de las incidencias detectadas. La transmisión de la respuesta se realizará por el mismo canal por el que se hizo el envío.

2.2.1 Estructura del archivo con el mensaje de respuesta

El archivo con el resultado de la depuración tiene formato de listado con líneas de 132 posiciones, sin carácter de control de carro, y 64 líneas por página.

(14)

ENCABEZAMIENTO ESTANDAR

Después una línea que identifica el inicio del mensaje enviado al PSP remitente de los datos, mediante el literal:

***** INICIO MENSAJE PARA REMITENTE: 999999 *****

En el caso de que se detecten errores al contrastar el archivo recibido con el esquema XML (TransExtPSP.xsd), el archivo será rechazado, sin ninguna depuración adicional, y se mostrará, a continuación, el mensaje de error A01 como bloque 0.

Bloque 0

Si se detectan errores en la cabecera del archivo telemático, supondrá el rechazo completo del mismo, sin depurar ningún movimiento, y se mostrará un mensaje como bloque C.

Bloque C

Si no se han detectado errores en la cabecera del archivo, se depurará la información por cada PSP declarante. Para cada uno de ellos, se imprimirá una línea que identifica el PSP del que se va a informar del resultado de la depuración; para ello se imprimirá el literal:

***** INICIO PSP: 999999 *****

Después se mostrará el resultado de la depuración para dicho PSP declarante como mensaje bloque 0.

Bloque 0

Adicionalmente, y sólo en el caso de que se hayan detectado errores y estos no superen los 100, estos se detallarán en uno de los siguientes bloques:

Bloque 1: Errores previos a la depuración de las transacciones. Informa de errores referidos a la validez del PSP remitente y/o declarante y a la coherencia entre periodos informados. Si está presente, no cabe la posibilidad de que se imprima el siguiente bloque, y va a suponer el rechazo completo de la información del PSP declarante.

O bien:

Bloque 2: Detalle de los errores detectados en las transacciones.

Al final del último bloque informado para cada PSP declarante, se imprimirá una línea con el siguiente literal:

***** FIN PSP: 999999 *****

Asimismo al final del listado, y como última línea del mismo se imprimirá el literal: ***** FIN MENSAJE PARA REMITENTE: 999999 *****

(15)

La impresión de cada bloque se inicia siempre en página nueva; si fuera necesario más de una página para la impresión de las líneas de detalle de un bloque, se repetirá el encabezamiento estándar y subcabeceras del bloque en las páginas sucesivas.

A continuación se detalla el diseño del archivo de datos:

Encabezamiento estándar

----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2----+----3— BANCO DE ESPAÑA ESTADISTICA

MADRID DATOS DE TRANSACCIONES CON EL EXTERIOR OPERACIONES CON EL EXTERIOR

MENSAJE ENVIADO POR PSP 999999 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX EN FECHA: dd-mm-aaaa HORA: hh:mm:ss DTEL501X PAG.: ZZZ9 RESULTADO DEPURACION PSP 999999 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX PERIODO: mm-aaaa

FECHA Y HORA DEPURACIÓN: dd-mm-aaaa hh:mm:ss TIPO DE DEPURACION: XXXXXXXX

Los datos que figuran en el encabezamiento estándar son:

Número

de línea Dato Columna Formato dato

Long. Dato

4 Código PSP Remitente 26 A 6

Fecha de recepción del mensaje en el Banco de España 79 dd-mm-aaaa 10

Hora de recepción del mensaje en el Banco de España 96 hh:mm:ss 8

Bloque o tipo de listado: C,0,1 y 2 119 A 1

Número de Página 127 N 4

5 PSP Declarante 26 A 6

Periodo 96 mm-aaaa 7

6 Fecha de depuración en el Banco de España 26 dd-mm-aaaa 10

Hora de depuración en el Banco de España 37 hh:mm:ss 8

Tipo de depuración 96 A 6

La línea 5, correspondiente a los datos del PSP declarante, va a blancos cuando se imprime el bloque "C".

Las líneas 5 y 6, correspondientes a los datos del PSP declarante y a la fecha-hora de depuración, van a blancos cuando se imprimen los errores A00 y A01.

(16)

Bloque C:

DTEL501C. Errores en la cabecera del archivo

----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2----+----3-- ***** INICIO MENSAJE PARA REMITENTE: 999999 *****

RESULTADO : ***** CON ERRORES *****

EN LA CABECERA:XXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ***** FIN MENSAJE PARA REMITENTE: 999999 *****

Los datos que figuran en las líneas del bloque "C" son:

Número

Long. Dato

8 ***** INICIO MENSAJE PARA REMITENTE: 1 A 36

Código PSP remitente 38 A 6

***** 45 A 5

11 Clave de error 41 A 3

Descripción del error 45 A 50

13 ***** FIN MENSAJE PARA REMITENTE: 1 A 33

Código PSP Remitente 38 A 6

***** 45 A 5

Las posibles claves de error y su descripción, para el bloque "C", son: B01 PSP remitente no válido

B02 PSP remitente no vigente

B03 Periodo declaración debe ser igual o posterior a 2012-06 B04 Periodo declarado no finalizado

(17)

Bloque 0:

DTEL5010. Resultado de la depuración

----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2----+----3-- ***** INICIO MENSAJE PARA REMITENTE: 999999 *****

***** INICIO PSP: 999999 *****

RESULTADO: XXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Los datos que figuran en las líneas del bloque "0" son:

Número

Long. Dato

8 ***** INICIO MENSAJE PARA REMITENTE: 1 A 36

Código PSP remitente 38 A 6

***** 45 A 5

10 ***** INICIO PSP: 10 A 17

Código PSP Declarante 28 A 6

12 Código del Resultado de la depuración 25 A 3

Literal del resultado de la depuración 29 A 80

La línea 10 no aparecerá cuando se detecten errores al contrastar el archivo recibido con el esquema XML y el archivo sea rechazado.

Las posibles claves de error y su descripción, para el bloque 0, son: A00 XML mal formado

A01 Archivo no validado con el esquema

A02 Más de 100 errores. Se ignora el resto de la información Z01 Sin errores de depuración

Z02 Con errores de depuración

Z11 Entidad no opera en periodo. Sin errores Z12 Entidad no opera en periodo. Con errores

(18)

Bloque 1:

DTEL5011. Errores previos a la depuración

----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2----+----3-- ERRORES PREVIOS A LA DEPURACIÓN

--- C.ERROR DESCRIPCIÓN --- --- XXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Los datos que figuran en las líneas del bloque "1" son:

Número

Long. Dato

8-12 Subcabecera del Bloque 1 1

13 Clave de error del bloque 1 3 A 3

Descripción del error del bloque 1 11 A 60

Las posibles claves de error y su descripción, para el bloque "1", son: B05 Sin información en el periodo anterior

B06 Información ya asimilada en el periodo C01 PSP declarante 999999 no válido C02 PSP declarante 999999 no vigente

C03 PSP remitente no autorizado para el PSP declarante 999999 C04 Opera en periodo y no comunica movimientos

(19)

Bloque 2:

DTEL5012. Errores en las transacciones

---+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----0----+----1----+----2----+----3--

COBROS Y PAGOS TRANSFRONTERIZOS ---

NUMORD TIPO MON IMPORTE IMPORTE EUROS F. CONTABLE NIF CLIENTE PAIS CTR PROP CATE SIS REFERENCIA OPERACION PAGO SEPA DATOS OPERACION ANTERIOR

IBAN CLIENTE IBAN CLIENTE CONTRAPARTIDA BIC PSP CLIENTE CONTRAP. --- --- --- --- --- 9999999 XXX XXX ZZZ.ZZZ.ZZZ.ZZZ.ZZZ.ZZZ,Z9 ZZZ.ZZZ.ZZZ.ZZZ.ZZZ.ZZZ,Z9 99999999 XXXXXXXXX XX XX XXXX XXXX XXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XX X 99999999 999999 9999999 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXX XXX - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXX - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

ABONOS Y ADEUDOS EN CUENTAS DE NO RESIDENTES

---

NUMORD TIPO MON IMPORTE IMPORTE EUROS F. CONTABLE PAIS DATOS OPERACION ANTERIOR. IBAN CLIENTE --- --- - --- --- --- --- ---- -- --- --- --- 9999999 XXX XXX ZZZ.ZZZ.ZZZ.ZZZ.ZZZ.ZZZ,Z9 ZZZ.ZZZ.ZZZ.ZZZ.ZZZ.ZZZ,Z9 99999999 XX X 99999999 999999 9999999 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXX - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXX - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

ENVIO Y RECEPCION DE REMESAS

--- NUMORD TIPO COD.ADU FEC ENV/REC FEC ABO/ADE PAIS DATOS OPERACION ANTERIOR.

SERIE IMPORTE EUROS SERIE IMPORTE EUROS SERIE IMPORTE EUROS SERIE IMPORTE EUROS --- --- --- --- --- --- --- --- 9999999 XXX XXXXXXX 99999999 99999999 XXX X 9999999 999999 9999999 ZZZ,Z9 ZZZ.ZZZ.ZZZ.ZZZ.ZZZ.ZZZ,Z9 ZZZ,Z9 ZZZ.ZZZ.ZZZ.ZZZ.ZZZ.ZZZ,Z9 ZZZ,Z9 ZZZ.ZZZ.ZZZ.ZZZ.ZZZ.ZZZ,Z9 ZZZ,Z9 ZZZ.ZZZ.ZZZ.ZZZ.ZZZ.ZZZ,Z9 ZZZ,Z9 ZZZ.ZZZ.ZZZ.ZZZ.ZZZ.ZZZ,Z9 ZZZ,Z9 ZZZ.ZZZ.ZZZ.ZZZ.ZZZ.ZZZ,Z9 ZZZ,Z9 ZZZ.ZZZ.ZZZ.ZZZ.ZZZ.ZZZ,Z9 ZZZ,Z9 ZZZ.ZZZ.ZZZ.ZZZ.ZZZ.ZZZ,Z9 ZZZ,Z9 ZZZ.ZZZ.ZZZ.ZZZ.ZZZ.ZZZ,Z9 ZZZ,Z9 ZZZ.ZZZ.ZZZ.ZZZ.ZZZ.ZZZ,Z9 ZZZ,Z9 ZZZ.ZZZ.ZZZ.ZZZ.ZZZ.ZZZ,Z9 ZZZ,Z9 ZZZ.ZZZ.ZZZ.ZZZ.ZZZ.ZZZ,Z9 ZZZ,Z9 ZZZ.ZZZ.ZZZ.ZZZ.ZZZ.ZZZ,Z9 ZZZ,Z9 ZZZ.ZZZ.ZZZ.ZZZ.ZZZ.ZZZ,Z9 ZZZ,Z9 ZZZ.ZZZ.ZZZ.ZZZ.ZZZ.ZZZ,Z9 XXX - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXX - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Los errores detectados en las transacciones de tipo 1 (cobros y pagos transfronterizos), en las transacciones de tipo 2 (abonos y adeudos en cuentas de no residentes) y en las transacciones de tipo 3 (envío y recepción de remesas), presentan las líneas del bloque "2" con los siguientes datos:

(20)

Número

Long. Dato

8-13 Subcabecera del bloque 2 4

14 Número de orden que identifica al registro con errores 1 N 7

18 Clave del error 10 A 3

Descripción del error 16 A 50

Las posibles claves de error y su descripción para el bloque "2", son: Grupo D para transacciones normales

D01 Moneda no vigente

D02 NIF residente mal composición D03 NIF residente no válido D04 Número de orden no consecutivo D05 País no vigente

D06 País corresponsal no vigente

D07 País contrapartida no vigente

D08 Propósito no vigente

D09 Categoría no vigente

D10 Sistema liq/comp no vigente D11 Referencia no válida

D12 Fecha contable no coherente

D13 Fecha envío/recepción no coherente D14 Fecha adeudo/abono no coherente D15 IBAN cliente mal composición D16 IBAN cliente debe comenzar por ‘ES’

D17 BIC PSP cliente contrapartida no puede contener ‘ES’ en sus posiciones 5ª y 6ª

D18 IBAN cliente contrapartida mal composición

D19 IBAN cliente contrapartida no puede empezar por ‘ES’ D20 Contravalor en euros mal calculado

D21 Nombre o razón social no válido D22 Concepto no válido

D23 PSP y cuenta cliente contrapartida no válido D24 Corresponsal extranjero no válido

D25 Descripción otras aduanas no válida D26 Pago SEPA no coherente con periodo D27 Moneda no coherente con pago SEPA

D28 IBAN cliente contrapartida obligatorio para pago SEPA D29 País contrapartida no coherente con pago SEPA

D30 IBAN cliente contrapartida y/o BIC PSP contrapartida no coherente(s) con país contrapartida

D31 PSP y cuenta cliente contrapartida obligatorio si IBAN cliente contrapartida no disponible

(21)

Grupo E para transacciones de baja1

E01 PSP declarante anterior distinto de declarante E02 Periodo declaración anterior fuera de rango E03 Transacción anterior inexistente E04 Datos no coinciden con la transacción rectificada E05 Transacción anterior es una rectificación de baja E06 Transacción anterior ya dada de baja E07 Transacción de baja duplicada

Grupo F para transacciones de alta2

F01 PSP declarante anterior distinto de declarante F02 Periodo declaración anterior fuera de rango

2.2.2 Ejemplos del archivo con el mensaje de respuesta

Ejemplo de estructura del archivo de datos si se producen errores en la cabecera del archivo:

Supongamos que el PSP 999999 remite un archivo telemático, con errores en la cabecera del archivo, comunicando datos propios y de otros PSP. En este caso, no se depuraría ningún movimiento, obteniéndose un listado de errores con la siguiente estructura:

ENCABEZAMIENTO ESTÁNDAR

***** INICIO MENSAJE PARA REMITENTE: 999999 ***** Bloque C

***** FIN MENSAJE PARA REMITENTE: 999999 *****

Ejemplo de estructura del archivo de datos si no se producen errores en la cabecera del archivo:

Si el mensaje depurado presentara datos de un solo PSP declarante, el formato podría ser el siguiente:

***** INICIO MENSAJE PARA REMITENTE: 999999 ****** ****** INICIO PSP: 999999 ******

Bloque 0 Bloque 2

****** FIN PSP: 999999 **********

1_{En las transacciones de baja de operaciones en las que no se comunicó PagoSEPA se realizará la depuración D26 detallada} anteriormente.

2_{En las transacciones de alta se realizarán para el resto de variables además de estas depuraciones las indicadas en el grupo D para las} transacciones normales.

(22)

****** FIN MENSAJE PARA REMITENTE: 999999 *******

Si el mensaje presentara datos de varias entidades declarantes, el formato podría ser el siguiente:

***** INICIO MENSAJE PARA REMITENTE: 999999 ****** ****** INICIO PSP: 999999 ****** Bloque 0 ****** FIN PSP: 999999 ********** : : ENCABEZAMIENTO ESTÁNDAR ****** INICIO PSP: 888888 ****** Bloque 0 Bloque 1 ****** FIN PSP: 888888 **********

****** FIN MENSAJE PARA REMITENTE: 999999 *******

2.3 Conservación de los datos

En el caso de que se detectara algún error en la información remitida, por parte del Banco de España, se solicitará la rectificación del mismo.

Sólo se admitirán rectificaciones que afecten a movimientos cuya fecha de comunicación anterior (PeriodoDeclaracionAnterior) resulte igual o inferior a 3 años.

Para el caso en el que los archivos originales plantearan problemas técnicos en alguno de los tratamientos que se hagan en el Banco de España, los PSP declarantes conservarán la información remitida por un plazo mínimo de 3 meses.

(23)

Apartado 3

(24)

(25)

3 Contenido de la información

3.1 Frecuencia y contenido de la información

Los PSP, de acuerdo con la Circular 1/2012 del Banco de España, estarán obligados a informar, a partir de junio de 2012, con periodicidad mensual y dentro de los diez días hábiles siguientes al fin de cada mes, de las operaciones indicadas a continuación:

1 Los cobros y pagos transfronterizos, así como las transferencias al o del exterior, cifrados en euros o en moneda extranjera, realizados por cuenta de sus clientes, cuando dichos cobros y pagos tengan origen o destino en cuentas abiertas en un proveedor de servicios de pago en otros Estados miembros de la Unión Europea o en cualquier otro país. No se incluirán aquellas operaciones cuyos titulares fueran otros proveedores de servicios de pago.

2 Los abonos y adeudos en cuentas de sus clientes no residentes. No se incluirán los movimientos de las cuentas cuyos titulares fueran otros proveedores de servicios de pago.

3 Los envíos y recepciones de billetes y moneda metálica en euros, a/de sus corresponsales extranjeros.

Las operaciones a las que se refieren los puntos 1 y 2 únicamente se comunicarán cuando su importe en euros o su contravalor en otra divisa sea superior a 50.000 €.

3.2 Tipos de transacciones

Las operaciones, a las que se refiere el apartado anterior, se comunicarán a través de tres tipos de transacciones, con las especificaciones recogidas en el apartado 4 de este documento. Estos tres tipos de transacciones son los siguientes:

Transacción de tipo 1: Para los datos correspondientes a los cobros/pagos transfronterizos y transferencias al/del exterior sin ningún tipo de limitación relacionada con la mensajería.

Transacción de tipo 2: Para los datos correspondientes a los abonos y adeudos en cuentas (a la vista y de ahorro) de no residentes, abiertas en PSP residentes.

Transacción de tipo 3: Para los datos correspondientes a los envíos y recepciones de billetes y moneda metálica en euros, a/de sus corresponsales extranjeros.

3.3 Identificación de las transacciones

Las transacciones quedarán identificadas por las variables PSPDeclarante,

PeriodoDeclaracion y NumeroOrden. La identificación de la transacción será la referencia en cualquier aclaración o rectificación posterior de la misma.

El número de orden, para cada tipo de transacción en el periodo declaración, empezará por el número 1, será correlativo y la última transacción será igual al total de transacciones contenidas en el archivo, no debiendo por tanto haber duplicidades o saltos.

(26)

3.4 Rectificaciones

A efectos de subsanar los datos erróneamente comunicados en periodos anteriores se usarán transacciones de rectificación.

Esta clase de transacciones serán comunicadas por los PSP, cuando así les sea indicado por el propio Banco de España o bien, cuando sea el propio PSP el que detecte el error al observar movimientos omitidos o incorrectos en meses anteriores.

De forma habitual, será el PSP quien rectificará los movimientos comunicados de forma errónea por él mismo. Ahora bien, de forma extraordinaria un PSP podrá rectificar las transacciones comunicadas al Banco de España por otro, cuando este último haya sido absorbido por el primero, o ambos se hayan fusionado.

La corrección de errores de comunicación en períodos posteriores se efectuará de acuerdo con el tipo de error mediante los siguientes procedimientos:

Tipo de error

- Omisión de una transacción en un período anterior.

o Se comunicará la transacción omitida mediante una transacción de rectificación de alta (RectifAltaPeriodoAnt).

- Inclusión errónea en un período anterior de una transacción.

o Se comunicará su eliminación mediante una transacción de rectificación de baja (RectifBajaPeriodoAnt).

- Contenido erróneo en alguna de las variables de una transacción comunicada en un período anterior.

o Se corregirá la transacción errónea mediante la comunicación de dos transacciones de rectificación, una de baja (RectifBajaPeriodoAnt), para la transacción inicialmente comunicada, y otra de alta (RectifAltaPeriodoAnt), para la transacción con el contenido correcto.

(27)

Apartado 4

(28)

(29)

4 Especificación de las transacciones y variables

4.1 Especificación de los archivos con las transacciones

Los archivos a enviar al Banco de España conteniendo las transacciones económicas con el exterior, que comunicarán los PSP, tendrán formato XML. El esquema XML de dichos archivos se especifica en el documento “TransExtPSP.xsd”.

En este apartado se detalla la estructura de los mencionados archivos y la definición de las variables que lo componen.

Cada archivo se compone de una información denominada cabecera, de la identificación del PSP declarante y de cada una de las transacciones que componen la comunicación. En el gráfico adjunto se detalla la estructura de los archivos:

4.1.1 Información de cabecera del archivo (Cabecera)

La información de cabecera del archivo constará de las siguientes variables:  PSPRemitente

 PeriodoDeclaracion

 FechaCreacion

(30)

4.1.2 Información del proveedor de servicios de pago declarante

(InformeDeclarante)

Para cada uno de los PSP declarantes de los que se remite información en el archivo, se deberán comunicar las siguientes variables:

 PSPDeclarante

 OperaEnPeriodo/NoOperaEnPeriodo

Si el PSP declarante, siendo comunicante habitual de este estado mensual no tuviera, en algún periodo determinado, ninguna de las operaciones que está obligado a declarar conforme a la Circular 1/2012, deberá hacerlo constar mediante la utilización de la variable NoOperaEnPeriodo.

En caso contrario, deberá emplear la variable OperaEnPeriodo para cumplimentar las variables de los tres tipos de transacciones: TransaccionesTipo1, TransaccionesTipo2 y/o TransaccionesTipo3 que se indican a continuación.

4.1.3 Información de transacciones

Para cada una de las transacciones deberá cumplimentar una serie de variables comunes, independientemente del tipo de transacción. Estas variables se describen a continuación.

4.1.3.1 Variables comunes a todos los tipos de transacciones

Se seleccionará si la transacción a comunicar corresponde al periodo de declaración (TransaccionNormal) o a un periodo anterior, bien para dar de baja la transacción

(RectifBajaPeriodoAnt) o bien para dar de alta una transacción (RectifAltaPeriodoAnt).

La corrección de errores de información comunicada en periodos anteriores se efectuará de acuerdo con los siguientes procedimientos:

 Inclusión errónea en un periodo anterior de una transacción.

Se comunicará su eliminación mediante una transacción de rectificación de baja (RectifBajaPeriodoAnt) que incluirá las variables siguientes:

 PSPDeclaranteAnterior

 PeriodoDeclaracionAnterior

 NumeroOrdenAnterior

 Omisión de una transacción en un periodo anterior.

Se comunicará mediante una transacción de rectificación de alta (RectifAltaPeriodoAnt) que incluirá las variables siguientes:

 PSPDeclaranteAnterior

(31)

 Contenido erróneo en alguna de las variables de una transacción comunicada en un periodo anterior.

Se corregirá mediante la comunicación de dos transacciones de rectificación: una de baja (RectifBajaPeriodoAnt) para la transacción inicialmente comunicada; y, otra de alta (RectifAltaPeriodoAnt) para la transacción con el contenido correcto. En el gráfico adjunto se detalla la estructura de variables descrita anteriormente.

4.1.3.2 TransaccionesTipo1: Cobros/pagos transfronterizos y transferencias al/del exterior

En la comunicación de transacciones de tipo 1 correspondientes, tanto al periodo de declaración (TransaccionNormal) como a periodos anteriores (RectifBajaPeriodoAnt/RectifAltaPeriodoAnt) habrán de cumplimentarse las siguientes variables:  FechaContable  NumeroOrden  TipoOperacion  Moneda  ImporteOperacion  ContravalorEuros

(32)

 Datos identificativos del cliente

Si se trata de un cliente residente, se especificará con la variable:

ClienteResidente y con las variables siguientes de dicho cliente:

 NIFClienteResidente

 NombreoRazonSocial

Si se trata de un cliente no residente, se especificará con la variable:

ClienteNoResidente y con las variables siguientes de dicho cliente:

 Pais

 PagoSEPA

 IBANCliente

 Concepto

Esta variable se cumplimentará cuando esté disponible en la mensajería.

 Proposito

 Categoria

 SistemaLiqComp

 ReferenciaOperacion

 PaisPSPClienteContrapartida

 CuentaClienteContrapartida

Los datos identificativos de la cuenta del cliente de contrapartida son:

 BICPSPClienteContrapartida

Esta variable se cumplimentará cuando esté disponible en la mensajería.  Identificación de la cuenta del cliente de contrapartida

La cuenta de contrapartida se identificará mediante la variable

IBANClienteContrapartida. Cuando no se disponga de esta variable,

entonces se identificará mediante la variable

(33)

(34)

4.1.3.3 TransaccionesTipo2: Abonos y adeudos en cuentas (a la vista y de ahorro) de no

residentes abiertas en PSP residentes

En la comunicación de transacciones de tipo 2 correspondientes tanto al periodo de declaración (TransaccionNormal) como a periodos anteriores (RectifBajaPeriodoAnt/RectifAltaPeriodoAnt) habrán de cumplimentarse las siguientes variables:  FechaContable  NumeroOrden  TipoOperacion  Moneda  ImporteOperacion  ContravalorEuros

 Datos identificativos del ClienteNoResidente

 Pais

 IBANCliente

(35)

El gráfico adjunto contiene el esquema de información de las transacciones de tipo 2.

4.1.3.4 TransaccionesTipo3: Envíos y recepciones de billetes y moneda metálica en euros

a/de sus corresponsales extranjeros

En la comunicación de transacciones de tipo 3 correspondientes tanto al periodo de declaración (TransaccionNormal) como a periodos anteriores (RectifBajaPeriodoAnt/RectifAltaPeriodoAnt) habrán de cumplimentarse las siguientes variables:

 FechaEnvioRecepcion

 FechaAdeudoAbono

 NumeroOrden

(36)

 Importes de las monedas y billetes enviados o recibidos

Para cada serie o valor facial de las monedas y billetes de euro se informará, además de ésta, del importe de la transacción.

 Denominacion

 Importe

 CorresponsalExtranjero

 PaisCorresponsal

 Aduana

Se cumplimentará la aduana o el puesto fronterizo por el que se realiza el envío o la recepción de monedas y/o billetes, con las especificaciones siguientes:

 CodAduana

Cuando el envío o recepción se realice por alguna de las aduanas especificadas para esta variable, se cumplimentará con el código de aduana correspondiente.

 DesOtrasAduanas

Cuando el envío o recepción se realice por una aduana o puesto fronterizo diferente de las especificadas para esta variable, se cumplimentará con el literal correspondiente al nombre de la misma.

(37)

El gráfico adjunto contiene el esquema de información de las transacciones de tipo 3.

4.1.4 Definición de las variables del esquema de información

Variable

Descripción

Aduana Se cumplimentará la aduana o el puesto fronterizo

por el que se realiza el envío o la recepción de monedas y/o billetes. Si la aduana corresponde a alguna de las que están codificadas, se especificará el código correspondiente (variable

CodAduana), si es otra aduana no codificada, se

especificará su nombre (variable

DesOtrasAduanas).

BICPSPClienteContrapartida Se indicará el código BIC del PSP no residente del

cliente de contrapartida de la operación cuando esté disponible en la mensajería3_.

Categoria Cuando esté disponible en la mensajería, debe

hacerse constar el código estandarizado correspondiente a la categoría, que ha de coincidir con uno de los valores contemplados para esta variable en el esquema.

(38)

Variable

Descripción

ClienteNoResidente Con esta variable se indica que el cliente de la

entidad es no residente.

ClienteResidente Con esta variable se indica que el cliente de la

entidad es residente.

CodAduana Cuando el envío o recepción se realice por alguna

de las aduanas especificadas para esta variable, se cumplimentará con el código de la aduana correspondiente.

Concepto En las operaciones de tipo 1, se cumplimentará,

cuando esté disponible en la mensajería, con el literal que describe la operación. En las operaciones de tipo 2, se cumplimentará con el concepto con el que se describe el apunte de adeudo/abono en la cuenta del cliente no residente.

ContravalorEuros Contravalor en euros del importe en la divisa

original de cada movimiento (variable

ImporteOperación).

CorresponsalExtranjero Razón social del corresponsal bancario extranjero

a quien se efectúa la remesa o de quien procede la misma.

CuentaClienteContrapartida Datos identificativos de la cuenta del cliente de

contrapartida.

Denominacion Serie o valor facial de la moneda o billete. Deberá

contener uno de los valores de la lista de denominación.

DesOtrasAduanas Cuando el envío o recepción se realice por una

aduana o puesto fronterizo diferente de las codificadas para esta variable, se cumplimentará con el literal correspondiente al nombre de la misma.

FechaAdeudoAbono Fecha de adeudo/abono en la contabilidad

patrimonial.

FechaContable Fecha en la que las operaciones se registran en la

contabilidad patrimonial.

FechaCreacion Fecha y hora de creación del fichero a remitir.

FechaEnvioRecepcion Fecha de envío/recepción de la remesa.

IBANCliente Se indicará el IBAN de la cuenta en España del

cliente residente o no residente, titular de la misma. En aquellas operaciones en que no se disponga del mismo, se rellenará con el valor “ES12 9999 9999 50 9999999999”.

(39)

Variable

Descripción

IBANClienteContrapartida Se indicará el IBAN de la cuenta en el exterior del

cliente de contrapartida de la operación para los pagos SEPA. En el resto de pagos se rellenará cuando esté disponible en la mensajería.

Importe Debe indicarse el importe de los billetes y

monedas metálicas clasificados por su denominación.

ImporteOperacion Importe de cada transacción en la divisa original.

IndicadorTest Esta variable sirve para identificar si los archivos

remitidos son en pruebas o no. Deberá contener uno de los valores especificados en el esquema para esta variable.

Moneda Debe indicarse uno de los códigos ISO alfabético

contemplados para esta variable en el esquema.

NIFClienteResidente Se indicará el NIF del residente al que corresponde

el cobro o pago exterior. En su composición cumplirá lo especificado en la normativa vigente.

NombreoRazonSocial Nombre o razón social correspondiente al cliente

residente o no residente según corresponda.

NoOperaEnPeriodo Si el PSP declarante, siendo comunicante habitual

de este estado mensual, en algún periodo determinado no tuviera ninguna de las operaciones a las que está obligado a declarar conforme a la Circular 1/2012, deberá hacerlo constar mediante la utilización de la variable

NoOperaEnPeriodo.

NumeroOrden Se asignará para cada periodo de declaración y

tipo de transacción, comenzando con el número 1 y terminando con el número que corresponda al total de transacciones informadas. Los números de orden deberán ser consecutivos.

NumeroOrdenAnterior Cuando se trate de dar de baja o de corregir una

transacción comunicada en un periodo anterior, se indicará el número de orden de la transacción

errónea en la declaración de dicho periodo.

OperaEnPeriodo Se indicará cuando el PSP declarante tenga

operaciones que comunicar en el periodo corriente.

PagoSEPA En las transacciones de tipo 1 se indicará si es o

no una operación realizada en el marco de la zona única de pagos SEPA, sujeta al cumplimiento de los requisitos técnicos especificados en el Reglamento (UE) 260/2012. Deberá contener uno de los valores contemplados en el esquema para esta variable.

(40)

Variable

Descripción

Pais En las transacciones de tipo 1 y 2 debe

cumplimentarse el país del cliente no residente con uno de los códigos ISO alfabético contemplados para esta variable en el esquema, que se corresponda con el del país de residencia del cliente.

PaisCorresponsal Se indicará uno de los códigos ISO alfabético

contemplados para esta variable en el esquema, que se corresponda con el del país de residencia del corresponsal bancario extranjero.

PaisPSPClienteContrapartida Se rellenará con uno de los códigos ISO alfabético

contemplados para esta variable en el esquema. Debe corresponderse con el del país del PSP donde está abierta la cuenta del cliente de origen (cobro)/ destino (pago) de los fondos.

PeriodoDeclaracion Mes y año al que corresponde la declaración.

PeriodoDeclaracionAnterior Mes y año al que corresponde la rectificación.

Proposito Cuando esté disponible en la mensajería SEPA,

debe hacerse constar el concepto estandarizado propio de la misma, que ha de coincidir con uno de los valores contemplados para esta variable en el esquema.

PSPDeclarante Debe indicarse el código, en el Registro de

Entidades del Banco de España, correspondiente al PSP declarante.

PSPDeclaranteAnterior Se indicará el código, en el Registro de Entidades

del Banco de España, correspondiente al PSP declarante de la transacción a corregir. De forma extraordinaria, un PSP podrá rectificar las transacciones comunicadas por otro, cuando éste haya sido absorbido por el primero o ambos se hubieran fusionado.

PSPRemitente Debe indicarse el código, en el Registro de

Entidades del Banco de España, correspondiente al PSP remitente que efectúe el envío de la información.

PSPyCuentaClienteContrapartida En aquellos casos en los que no se haya podido

cumplimentar IBANClienteContrapartida deberá indicarse, siempre que esté disponible, el literal que describa al PSP y la cuenta de origen (cobro)/destino (pago). Si no se dispusiera de ninguno de ellos se rellenará con el literal ‘No disponible’.

(41)

Variable

Descripción

RectifAltaPeriodoAnt Con esta variable se indica que la transacción

comunicada es un alta correspondiente a un periodo anterior que no fue comunicada o que contenía información errónea que previamente ha sido dada de baja con la variable

RectifBajaPeriodoAnt.

RectifBajaPeriodoAnt Con esta variable se realiza la baja de una

transacción, comunicada por error en un periodo anterior o que contenía información errónea y que será rectificada con una nueva transacción con la variable RectifAltaPeriodoAnt.

ReferenciaOperacion Identificador interno de la operación asignado por

el PSP y conocido por su cliente.

SistemaLiqComp Código del sistema de compensación o

liquidación utilizado. Deberá contener uno de los valores especificados en el esquema para esta variable.

TransaccionNormal Con esta variable se indica que la transacción

comunicada es una transacción normal del periodo corriente.

TipoOperacion Deberá contener uno de los valores especificados

en el esquema para esta variable. Existen listas de valores diferentes para cada uno de los tipos de transacción.

(42)

(43)

Apartado 5

(44)

(45)

5 Criterios de depuración de los archivos

5.1 Criterios de depuración con el esquema XML

5.1.1 Controles previos al envío

La información de transacciones económicas con el exterior de los PSP se enviará al Banco de España mediante la transmisión de ficheros con formato XML (http://www.w3.org/XML/). XML es un metalenguaje de etiquetas que permite definir una “estructura válida” para los datos mediante la construcción de un esquema XML (http://www.w3.org/XML/Schema). Es habitual referirse a estos documentos de esquema como “XML Schema”.

El Banco de España ha elaborado un documento “XML Schema” que define sintácticamente cual es el formato correcto para los archivos que los PSP tendrán que enviar al Banco de España. Cualquier fichero que los PSP envíen al Banco de España y no cumpla con la estructura definida en el documento “XML Schema” será rechazado completamente. Por este motivo se recomienda que los informantes validen que el archivo es sintácticamente correcto antes de enviarlo al Banco de España. Para realizar esta validación se utilizará el esquema XML “TransExtPSP.xsd” que se facilita a los informantes.

5.1.2 Descripción de la estructura y validaciones realizadas en el esquema XML

“TransExtPSP.xsd”

El fichero XML que los PSP informantes enviarán al Banco de España tendrá el siguiente formato:

5.1.3 Declaración XML

El XML tiene que incluir una declaración explícita que contendrá la versión de XML y la codificación admitida que será UTF-8 en todos los casos.

<?xml version="1.0" encoding="UTF-8"?>

5.1.4 Elemento Raíz <Informe>

El elemento raíz será un elemento etiquetado como <Informe> que contendrá siempre los siguientes elementos y en el siguiente orden:

<Cabecera> - contendrá datos básicos del PSP que remite la información, de la fecha a la que corresponde la información y la fecha en que el informe fue generado. <InformeDeclarante> - Podrán aparecer uno o varios de estos elementos. Uno por

cada PSP declarante que está incluido en el informe.

…………Información incluida en la cabecera……… </Cabecera>

(46)

…………Información correspondiente a un declarante……… </InformeDeclarante>

…………Información correspondiente a un declarante……… </InformeDeclarante>

…………Información de otros declarantes ……… </Informe>

5.1.5 Elemento <Cabecera>

El elemento <Cabecera> incluye los siguientes elementos que deben aparecer siempre y en el siguiente orden:

<PSPRemitente> – Se validará que su contenido sea una cadena alfanumérica de entre 4 y 6 caracteres, sin blancos.

<PeriodoDeclaracion> – Se validará que su contenido sea una fecha con formato año y mes. El año se escribirá con 4 caracteres y el mes con 2 separados por un ‘-‘. Ejemplo: “2012-08”.

<FechaCreacion> – Se validará que su contenido sea de tipo fecha y hora con el formato YYYY-MM-DDThh:mm:ss donde:

YYYY representa el año escrito con cuatro cifras. MM representa el mes escrito con dos cifras. DD representa el día escrito con dos cifras.

T indica que comienza la indicación de las horas, minutos y segundos. hh representa la hora con dos cifras.

mm representa el minuto con dos cifras. ss representa los segundos con dos cifras. Ejemplo: “2012-09-09T09:30:00”.

<IndicadorTest> – Se validará que su contenido sea “Si” para indicar que es un envío de Test o “No” para indicar que el envío es de datos reales.

5.1.6 Elemento <InformeDeclarante>

Existirá un elemento <InformeDeclarante> por cada PSP declarante que esté incluido en el documento. Cada elemento <InformeDeclarante> contendrá siempre los siguientes elementos y en el siguiente orden:

<PSPDeclarante> - Se validará que su contenido sea una cadena alfanumérica de entre 4 y 6 posiciones. Además se validará que el PSPDeclarante sea único en el informe, es decir que el mismo PSPDeclarante no puede aparecer más de una vez. <OperaEnPeriodo>/<NoOperaEnPeriodo> - Aparecerá uno de estos dos elementos

pero no ambos indicando:

<OperaEnPeriodo>- La descripción de las validaciones sobre el contenido de esta etiqueta aparece en su epígrafe correspondiente.

(47)

<NoOperaEnPeriodo> – Este elemento no tendrá contenido ninguno.

……Transacciones correspondientes al PSP Declarante ……… </OperaEnPeriodo> </InformeDeclarante> <InformeDeclarante> <PSPDeclarante>PSP1</PSPDeclarante> <NoOperaEnPeriodo/> </InformeDeclarante>

…………Informes de otros declarantes ………

5.1.7 Elemento <OperaEnPeriodo>

El elemento <OperaEnPeriodo> contendrá tantos elementos como transacciones informe en el periodo de referencia del informe. Estas transacciones se cumplimentarán incluyendo los siguientes elementos tantas veces como transacciones sea necesario informar para cada tipo de registro:

<TransaccionTipo1> - Elemento utilizado para informar cada cobro o pago transfronterizo derivado de transferencias y adeudos directos. Las validaciones que se hacen sobre este elemento se describen en el epígrafe correspondiente.

<TransaccionTipo2> - Elemento utilizado para informar cada abono o adeudo en cuentas (a la vista y de ahorro) de no residentes, abiertas en PSP residentes. Las validaciones que se hacen sobre este elemento se describen en el epígrafe correspondiente.

<TransaccionTipo3> - Elemento utilizado para informar cada envío o recepción de billetes y moneda metálica en euros, a/de sus corresponsales extranjeros. Las validaciones que se hacen sobre este elemento se describen en el epígrafe correspondiente.

<OperaEnPeriodo> <TransaccionTipo1>

………Información de una transacción de tipo 1………

</TransaccionTipo1>

…………Otras transacciones Tipo 1………

<TransaccionTipo2>

(48)

<TransaccionTipo3>

</TransaccionTipo3>

</OperaEnPeriodo>

5.1.8 Elemento <TransaccionTipo1>

Este elemento contiene toda la información referente a un cobro o pago transfronterizo. El esquema validará que contenga los siguientes elementos y en el orden en el que se indican a continuación:

<TransaccionNormal>/<RectifBajaPeriodoAnt>/<RectifAltaPeriodoAnt> - Siempre hay que informar uno y sólo uno de estos 3 elementos, siendo excluyentes entre sí dentro de la misma transacción. El elemento <TransaccionNormal> no tiene contenido y las validaciones que se hacen sobre los elementos <RectifBajaPeriodoAnt> y <RectifAltaPeriodoAnt> están descritas en los respectivos epígrafes.

<FechaContable> - Elemento obligatorio con formato año(4 mes(2 cifras)-día(2 cifras). Ejemplo: 2012-07-15.

<NumeroOrden> - Contendrá un número entero que puede estar entre 1 y 9999999. Se comprobará que este número es único para todas las transacciones de tipo 1 que se incluyan en cada informe.

<TipoOperacion> - Puede tomar los valores “COB” para el caso de un cobro o “PAG” para el caso de un pago.

<Moneda> - Este elemento tendrá que contener el código ISO de una de las monedas válidas para el sistema.

<ImporteOperacion> - Es un número de 18 cifras de las cuales 2 pueden ser decimales. Se validará que el valor sea mayor que 0.00.

Ejemplo: 123456789012345678 es válido, 1234567890123456.78 es válido, pero 123456789012345678.12 no es válido.

<ContravalorEuros> - Es un número de 18 cifras de las cuales 2 pueden ser decimales. Se validará que el valor sea estrictamente mayor que 50000.00.

<ClienteResidente>/<ClienteNoResidente> - Uno y solo uno de los dos elementos tendrá que estar incluido. Las validaciones sobre ambos elementos se describen en los epígrafes correspondientes.

<PagoSEPA> - Se validará que contenga uno de los siguientes valores: "SI, "NO", "NA".

(49)

<IBANCliente> - Se validará que el formato del IBAN es correcto.

<Concepto> - Este elemento es opcional. Si aparece contendrá una cadena de 175 caracteres como máximo.

<Proposito> - Este elemento es opcional. Si aparece tendrá que contener un código de propósito de los admitidos en la mensajería SEPA.

<Categoria> - Este elemento es opcional. Si aparece tendrá que contener un código de categoría de los admitidos en la mensajería SEPA.

<SistemaLiqComp> - Se validará que contenga uno de los siguientes valores “TGT”, “EBA”, “ABE”, “ST2”, “CAM”, “CRR”, “OTR”.

<ReferenciaOperacion> - Se validará que sea una cadena de 35 caracteres como máximo.

<PaisPSPClienteContrapartida> - Se validará que contenga el código ISO de un país.

<CuentaClienteContrapartida> - Las validaciones al contenido de este elemento vienen descritas en su correspondiente epígrafe.

<TransaccionTipo1> <TransaccionNormal/> <FechaContable>2017-01-02</FechaContable> <NumeroOrden>1</NumeroOrden> <TipoOperacion>COB</TipoOperacion> <Moneda>USD</Moneda> <ImporteOperacion>12345678.43</ImporteOperacion> <ContravalorEuros>11414273.69</ContravalorEuros> <ClienteResidente> <NIFClienteResidente>B12345678</NIFClienteResidente> <NombreoRazonSocial>Ejemplo2 SL</NombreoRazonSocial> </ClienteResidente> <PagoSEPA>NO</PagoSEPA> <IBANCliente>ES9999999999994444444444</IBANCliente> <Concepto>Préstamo</Concepto> <Proposito>LOAN</Proposito> <Categoria>LOAN</Categoria> <SistemaLiqComp>TGT</SistemaLiqComp> <ReferenciaOperacion>123445</ReferenciaOperacion> <PaisPSPClienteContrapartida>FR</PaisPSPClienteContrapartida> <CuentaClienteContrapartida> <BICPSPClienteContrapartida>BANCFRM1XXX</BICPSPClienteContrapartida> <IBANClienteContrapartida>FR9911112222333344445M55666</IBANClienteCon trapartida> </CuentaClienteContrapartida> </TransaccionTipo1>

(50)

5.1.9 Elemento <TransaccionTipo2>

Este elemento contiene toda la información referente a un abono o adeudo en cuentas (a la vista y de ahorro) de no residentes, abiertas en PSP residentes.

El esquema validará que contenga los siguientes elementos y en el orden en el que se indican a continuación:

<FechaContable> - Elemento obligatorio con formato año (4 mes (2 cifras)-día (2 cifras). Ejemplo: 2012-07-15.

<TipoOperacion> - Puede tomar los valores “ABO” para indicar que la transacción corresponde a un abono o “ADE” para indicar que es un adeudo.

<Moneda> - Este elemento tendrá que contener el código ISO de una de las monedas válidas para el sistema.

<ImporteOperacion> - Es un número de 18 cifras de las cuales 2 pueden ser decimales. Se validará que el valor sea mayor que 0.00.

<ContravalorEuros> - Es un número de 18 cifras de las cuales 2 pueden ser decimales. Se validará que el valor sea estrictamente mayor que 50000.00.

<ClienteNoResidente> - Las validaciones sobre este elemento se describen en el epígrafe correspondiente.

<IBANCliente> - Se validará que sea un alfanumérico y corresponda con el formato de los códigos IBAN.

<Concepto> - Elemento obligatorio de texto libre con una longitud máxima de 175 caracteres. <TransaccionTipo2> <TransaccionNormal/> <FechaContable>2012-08-24</FechaContable> <NumeroOrden>5</NumeroOrden> <TipoOperacion>ADE</TipoOperacion> <Moneda>EUR</Moneda>

(51)

DEPARTAMENTO DE ESTADÍSTICA – APLICACIONES TÉCNICAS DE LA CIRCULAR 1/2012 45 <ImporteOperacion>52000</ImporteOperacion> <ContravalorEuros>52000</ContravalorEuros> <ClienteNoResidente> <NombreoRazonSocial>MRT</NombreoRazonSocial> <Pais>GB</Pais> </ClienteNoResidente> <IBANCliente>ES9999999999991111111111</IBANCliente> <Concepto>BONOS</Concepto> </TransaccionTipo2> 5.1.10 Elemento <TransaccionTipo3>

Este elemento contiene los elementos que componen la información de un envío o recepción de billetes y moneda metálica en euros, a/de corresponsales extranjeros. Se validará que incluya los siguientes elementos en el mismo orden en el que aparecen a continuación:

<FechaEnvioRecepcion> - Elemento obligatorio con formato año (4 cifras)-mes (2 cifras)-día (2 cifras). Ejemplo: 2012-07-15.

<FechaAdeudoAbono> - Elemento obligatorio con formato año (4 cifras)-mes (2 cifras)-día (2 cifras). Ejemplo: 2012-07-15.

<TipoOperacion> - Puede tomar los valores “ENV” para indicar que la transacción corresponde a un envío o “REC” para indicar que es una recepción.

<Importe> - Este elemento puede aparecer de una a 15 veces. Cada vez que aparezca deberá tener un atributo ‘Denominacion’ que podrá tomar los valores de alguna de las denominaciones de monedas o billetes válidos (Ej.: Denominacion=”20EUR” o Denominacion=”0.02EUR”). La ‘Denominacion’ no se puede repetir dentro de la misma TransaccionTipo3. En su contenido llevará el importe enviado o recibido de esa denominación que tendrá que ser un número de 18 cifras de las cuales 2 pueden ser decimales y que tendrá que ser mayor que 0.00. Ejemplo:

<Importe Denominacion="50EUR">89600</Importe> <Importe Denominacion="0.02EUR">456.54</Importe>

(52)

<PaisCorresponsal> - Se validará que contenga el código ISO de un país. <Aduana> - Contendrá uno y solo uno de los siguientes elementos:

<CodAduana> - Se validará que contenga uno de los siguientes valores: “BARAJAS”, “PRAT”, “LINEA”, “FARGA”.

<DesOtrasAduanas> - Se utiliza para el caso de que la aduana no esté codificada y se validará que sea una cadena de máximo 60 caracteres.

<CorresponsalExtranjero>SUCURSAL FR</CorresponsalExtranjero> <PaisCorresponsal>FR</PaisCorresponsal> <Aduana> <DesOtrasAduanas>Otra Aduana</DesOtrasAduanas> </Aduana> </TransaccionTipo3> 5.1.11 Elemento <RectifBajaPeriodoAnt>

Este elemento se utiliza para indicar que la transacción se había informado en un periodo anterior y se quiere dar de baja. Debe incluir los siguientes elementos y en el orden que se indica:

<PSPDeclaranteAnterior> - Se validará que el elemento contenga una cadena alfanumérica de entre 4 y 6 posiciones.

<PeriodoDeclaracionAnterior> - Se validará que el elemento contenga una fecha con formato año y mes. El año se escribirá con 4 caracteres y el mes con 2 separados por un ‘-‘. Ejemplo: “2011-12”.

<NumeroOrdenAnterior> - Corresponde al número que tenía la orden en el informe anterior. Se validará que este elemento sea un número entero que puede estar entre 1 y 9999999. <RectifBajaPeriodoAnt> <PSPDeclaranteAnterior>PSP1</PSPDeclaranteAnterior> <PeriodoDeclaracionAnterior>2012-06</PeriodoDeclaracionAnterior> <NumeroOrdenAnterior>86</NumeroOrdenAnterior> </RectifBajaPeriodoAnt>