ITA — telematic file exchange with the Banco de España

Every Spanish supervisory return has to travel somewhere, and for the Banco de España that somewhere is ITA — four channels, one enrolment letter per process, and a character-set rule that breaks files silently. Intercambio Telemático de Archivos is the framework the Banco de España uses for exchanging data files with supervised institutions, published as Instrucción Externa 2005.24. It is the Spanish counterpart of ONEGATE, INFOSTAT or the Dutch DLR, and it is far less forgiving, because the general framework and the per-return rules live in two different documents. This piece covers the channels, enrolment, certificates, the encoding trap and three worked cases.

1. What ITA is, and what it is not

ITA is not a portal and not a return. It is the Banco de España’s general instruction on how files move between an institution and the Bank — which transport channels are accepted, which encryption applies to each, how an institution is enrolled, and what a data file must physically look like.

What ITA deliberately does not settle is anything specific to a given return. The instruction says that the department that owns the information writes its own specific instructions and guidance for each exchange process — referred to as the Manual de Uso, though it may carry a different title — and that this document also states which communication channels are permitted for that process, and may set submission windows different from the general ones.

2. The four channels

ITA lists the channels the Banco de España accepts generically for telematic file transmission, each with its own access-control mechanism:

The general rule is that files exchanged between institutions and the Bank travel encrypted, confidential or not. Availability, unless a process says otherwise, is 08:00 to 22:00, Monday to Friday, excluding national and European holidays — and ITA warns that sending files outside the foreseen periods can produce errors or leave the file unprocessed.

Two channels carry conditions worth planning around. EDITRAN requires the institution to hold a licence for the product on a supported platform, and runs over TCP/IP with the encryption options determined by the network link used. FileAct requires the institution to hold the technical means SWIFT specifies and to have subscribed, through SWIFT’s e-ordering process, to the closed user groups bde.eca.sf! for pilot and bde.eca.sf for live. All transmission costs, traffic included, fall on the institution. Because FileAct is store-and-forward, the institution can send and receive whenever the service is available — the one channel whose timing is not gated by the Bank’s own window.

3. Enrolment is per process, not per institution

This is the single most misunderstood point. Attaching an institution to a process that involves telematic file exchange is done by sending a signed letter to the Banco de España following the model in the instruction’s first annex. The letter must state the institution’s general details, the process it wishes to join, the chosen communication channel and the security mechanism to be used with it.

The letter must be signed by hand by a person recognised by the department that receives the information. It may instead be sent as an e-mail signed with a legal-person certificate issued to the institution by a certification service provider the Bank accepts.

The sequence after that is fixed. The competent department approves the adhesion; the information systems department then performs the configuration needed to send and receive the institution’s files by the chosen mechanisms; the institution performs its own configuration; and the sender of the letter, or the named technical contact, receives an e-mail confirming the channel is available for that process. ITA specifically advises naming as technical contact someone who can resolve communication incidents during transmissions — not the regulatory reporting owner, but someone who can act when a transfer fails at 21:40.

The consequence for planning: an institution already exchanging files with the Bank for one return is not thereby enrolled for another. Each process needs its own letter, its own channel choice and its own security declaration.

4. Certificates, and the one mistake that leaks a private key

For ITW, authentication, send authorisation and the creation of the security environment use, preferentially, component electronic certificates issued by the Banco de España, which the instruction describes as best suited to the channel. Legal-person certificates issued by a certification service provider recognised by the Bank are also accepted, and the Bank publishes the list of recognised providers on its public-key infrastructure pages. A process’s own Manual de Uso may narrow what is acceptable further.

ITA carries an explicit warning that belongs in every runbook: when supplying a certificate, it is very important not to send it in .pfx or .p12 format, because doing so also hands over a copy of the associated private key, with the corresponding security risk. The instruction also covers key backup, authorising an institution to a process, authorising additional certificates to a process the institution already uses, and de-authorising certificates — four distinct procedures that a certificate rotation has to walk through in order.

5. The encoding trap

Data files sent to the Banco de España may undergo character-set conversion once prepared for processing — from ASCII to EBCDIC and back. Because of that, ITA makes it obligatory to use exclusively the character set detailed in its annex, the juego normal de caracteres, or the narrower one a particular Bank information system may require. Using different characters can cause processing errors.

The physical format then differs by channel, and this is where teams get caught:

• ITW and internet e-mail — a text file in extended ASCII (code page 850, MS-DOS Multilingual) or ISO 8859-1 (Latin-1), at the institution’s choice per process, unless the Manual de Uso fixes one. Each record ends with LF (hex 0A); trailing spaces before the LF may be omitted; the last record may optionally carry an EOF marker (hex 1A).
• EDITRAN — a text file in EBCDIC.

One file per transmission, in every case. The EBCDIC requirement is the trap: EDITRAN is also the channel Spanish institutions use for the financial ownership file to the financial intelligence unit, and that file is specified in ISO 8859-1. Same product, same protocol, opposite encoding — because the two instructions belong to two different authorities.

6. Three worked cases

Case 1 — reusing the EDITRAN link you already have. An e-money institution already sends its monthly account-ownership file over EDITRAN and is asked to start a Banco de España return. The reporting lead assumes the existing link covers it. Two things are wrong. Enrolment is per process, so a new signed letter is needed naming the new process, the channel and the security mechanism. And the file the generator produces in ISO 8859-1 will be wrong for the Bank over EDITRAN, which takes EBCDIC. The fix is to treat encoding as a per-destination setting in the generator, not a global one, and to run a test transmission before the first live window.

Case 2 — FileAct that is ordered but not homologated. A group with an existing SWIFT footprint chooses FileAct, submits the annex letter and completes the e-ordering for both closed user groups. Nothing transmits in production. The missing step is the basic connectivity testing that ITA requires in the pilot and live environments after the process enrolment and the approved e-orderings — and which is a prerequisite for enabling file transmission in production for the requested process. The Bank coordinates and schedules those tests with the institution. An institution that has already passed basic homologation testing does not repeat it, which is why a group’s second FileAct process goes live far faster than its first.

Case 3 — the file that expired before anyone collected it. The Bank makes files destined for an institution available for authorised users to collect through ITW, and they remain available only for a determined period, after which they cease to be available. On EDITRAN the mirror problem is delivery: files are attempted for a determined period, after which pending files stop being sent, so the receiving infrastructure and software must be ready inside the foreseen window — ITA singles out having the reception buffer ready as the condition for completing the transmission successfully. The operational answer is to treat collection as a scheduled task with an alert, not as something done when someone notices.

7. What to do, today

• Pair every Spanish return with two documents in your control library: ITA for transport and file physics, and that return’s Manual de Uso for channels, windows and any tighter character set.
• Keep an enrolment register — one row per process, with the channel, the security mechanism, the date of the signed letter and the confirmation e-mail. It is the fastest answer to “are we set up for this?”
• Make encoding a per-destination setting. EBCDIC for EDITRAN to the Bank; extended ASCII or ISO 8859-1 for ITW and e-mail; whatever the return’s own manual fixes, where it fixes one.
• Name a technical contact who can act during a transmission, and keep that name current — a stale contact turns a ten-minute failure into a missed window.
• Write the .pfx rule into the certificate procedure explicitly, and treat certificate authorisation, addition and de-authorisation as three separate change requests.
• Schedule collection, not just submission. Inbound files from the Bank expire; put the retrieval on the same calendar as the return.

Related: EDITRAN and how SEPBLAC files move · Banco de España payment statistics under Circular 2/2022 · Supervisory reporting channels compared across the EU · The Spanish reporting calendar