ONEGATE — the Banque de France reporting channel

A French return is never late because the numbers were late. It is late because nobody was accredited on the right collection, or the certificate expired, or the file went in as an Invio when it should have been a correction. ONEGATE is the single window through which a payment or e-money firm delivers almost everything the Banque de France and the ACPR ask for, and it has its own vocabulary, its own enrolment clock and its own idea of what “submitted” means. This piece sets out how the channel actually works — the two transmission modes, the accreditation path, what happens to a file after upload, and how to read the acknowledgement.

1. What ONEGATE is

ONEGATE is the Banque de France’s collection window. The name is an acronym the Bank spells out in its own user guide: Organisation Nouvelle des Échanges via un Guichet d’Alimentation et de Transferts vers l’Extérieur. In plain terms it is one authenticated portal, in front of many separate data collections, that lets each collection define its own format and its own cadence while the reporting firm deals with a single set of credentials.

ONEGATE is not a return. It is the pipe. The obligations live elsewhere — prudential statements, the balance-of-payments regulation, the payment-security collections — and each arrives at the portal as a domaine with its own reports, periods and validation rules. Documentation for banking-sector collections is published separately, on the Bank’s dedicated eSurfi site, rather than inside the portal.

Four terms recur throughout and are worth fixing, because the portal’s screens and its error messages use them literally:

The déclarant/remettant split is not cosmetic. Rights in ONEGATE are granted per collection and déclarant pair, which means a group that reports for several French entities, or a firm that uses an external filing agent, has to think about the matrix rather than about “an account”.

2. Two channels, and two strengths of authentication

ONEGATE offers a human channel and a machine channel.

The U2A channel (user to application) is the web interface. It supports two authentication strengths, and which one applies depends on the sensitivity of the collection rather than on the firm’s preference: weak access is an email address and a password; strong access requires an authentication certificate. The two run on separate production hostnames — onegate.banque-france.fr for weak and onegate-strong.banque-france.fr for strong — each with a matching homologation (test) environment. Certain surveys, the Bank’s guide names DATAGAPS and DATABRI among them, are certificate-only.

The A2A channel (application to application) removes the browser entirely and comes in two protocols. One is an EAI link, which requires a route to be built between the Bank’s systems and the firm’s. The other is a web service call, which requires a machine connection certificate and a dedicated URL. Neither is self-service: both are set up with the Bank, and the technical notice describing them is published alongside the portal documentation.

Three consequences follow, all routinely discovered late. The certificate the portal accepts is an X.509 file exported in base-64 .CER form — public key only. Renewal is not automatic on the Bank’s side: the new certificate must be sent to ONEGATE support so the account is updated, which makes expiry a diarised task rather than an IT surprise. And on the password side, users are prompted to change their password every 63 calendar days, though on some collections, depending on sensitivity, passwords may not expire at all.

3. Accreditation is the critical path

Access is requested from the portal’s own login page, and the request itself carries most of the friction.

The identifier is an email address, and it must be nominative and professional. A generic address or a shared mailbox cannot be used as an identifier. For a compliance function that habitually files from reporting@, that is a structural change: the person is the account, and cover during holidays is a second accredited person, not a shared login.

The request then forks on a single question — do you have an accreditation code? Some collections are available exclusively by code, issued by the business referent. Where there is no code, the requester instead selects the collections and déclarants the request covers, and an acknowledgement email summarising it is sent to the address given.

Validation is then performed by a collection manager, and — this is the part that surprises project plans — it is performed per collection/déclarant pair. A successful request produces one email carrying a provisional password and a further confirmation email for each pair. A refusal produces an email carrying the reason, again for that pair. It is entirely normal to be accredited on one collection and refused on another from the same request.

Once inside, the Profil page manages the matrix: it lists every validated authorisation with its roles, and carries the function for requesting rights on a new déclarant/domain pair.

4. Making a remise

There are two ways to get data in, and they leave different traces.

File loading. The home page carries a Chargement de fichiers area that accepts .xml and .xbrl files, signed or unsigned, with .ZIP compression permitted. Files can be dragged in or selected, several at a time; the Envoyer button becomes available once a file is staged. On send, the file moves to en cours d’intégration and a ticket number appears, which is the handle for everything that follows.

Online entry. The Rapports menu reaches the same obligations as web forms, searchable either by domain (domain code, report code, report label) or by déclarant. A period is selected from a list ordered most recent first, and each period carries two attributes worth reading before keying anything: a life cycle — Initial, Ouvert or Fermé — and a state — Ok, Alerte or Erreur. On some surveys a .CSV can be imported into the form instead of keying, in either Ajout or Remplace mode; the file must be UTF-8 and the encoding selected explicitly. An Historique des imports tab keeps the imported CSVs, and an anomaly report for each can be viewed in the interface or downloaded as XML. The form is finally closed and sent with the padlock control.

Deliveries made through online entry are visible in the same tracking screens as file deliveries, but their ticket identifiers are prefixed with N-. That prefix is the fastest way to tell, months later, whether a given period was keyed or loaded — which matters when a correction has to reproduce the original method.

5. Reading the acknowledgement

The Suivi > Suivi des remises screen lists deliveries with searchable columns, a filter by processing status, and a CSV export of whatever the filters return. Opening a ticket gives the delivery detail, and this is where the real answer lives: each processing step carries its own status, and there are exactly three values — Succès, Avertissement, Échec. A Messages column shows how many messages each step raised; where the count is not zero, the messages can be opened, and for many steps the processing report can be downloaded.

For signed deliveries the detail screen adds a signature block that reports four things separately: the signatory, the validity of the signature, the validity of the certificate and the validity of the habilitation. The fourth is the one that fails silently in practice — a technically valid signature from a person whose rights on that collection/déclarant pair have lapsed.

Notifications are configurable per email address in the Profil page, across three types: notification de remise for messages tied to a delivery, notification de retard for late-filing reminders, and notification métier for business collection reports. A2A reporters can have recipients attached too, but only by asking support to link the addresses to the A2A account — it is not configurable from the interface.

The portal’s old messaging function has been replaced by document management: Suivi > Documents lists everything received, by domain and déclarant, with the document type — CRC, late-filing reminder and others — plus the reporting date, a file description and a download link.

6. Three scenarios

Scenario one: the branch that cannot file. A payment institution passporting into France opens a branch and appoints its group reporting team, sitting in another Member State, to file. Facts to rule: rights are granted per collection/déclarant pair, and the identifier must be a nominative professional email, not a shared box. What the team does: name two individuals, register each separately, request the pairs for the French déclarant explicitly, then check Profil shows each pair validated rather than merely requested. The failure mode is one accredited person going on leave in the week a quarterly return closes.

Scenario two: the certificate nobody owned. A firm reports on a certificate-only collection through the strong channel. The certificate is renewed by the IT team as part of routine PKI hygiene. Facts to rule: renewal requires the new certificate to be sent to ONEGATE support so the account is updated, and the file must be the base-64 .CER export. What the compliance officer does: put certificate expiry in the reporting calendar next to the filing deadlines, not in the IT asset register, and re-test in homologation after renewal. The failure mode is a valid new certificate that the portal has never seen.

Scenario three: the correction that overwrote nothing. A firm keys a period through the Rapports forms, then discovers an error after closing and sending. Facts to rule: the period life cycle and state are visible before anything is re-opened, and online-entry deliveries carry the N- ticket prefix. What the analyst does: look at the period first — one showing Fermé cannot simply be re-keyed — retrieve the original ticket, and follow the correction route the collection defines rather than assuming a second delivery supersedes the first. Outcome: one authoritative version. The failure mode is two deliveries and no evidence of which one the Bank holds.

7. Planning around the channel

The sequencing that works: identify the domains before the deadlines; request accreditation the moment the entity is authorised rather than the month the first return falls due; and treat the homologation environments as part of the build. The Bank publishes separate test hostnames for both weak and strong access precisely so that the first production delivery is not the first delivery.

Two support facts belong in the runbook, because they determine what can be resolved on a filing day. ONEGATE support is available from 08:00 to 19:00, by phone on 01 42 92 60 05 and at Support-OneGate@banque-france.fr. And the home page carries colour-coded notes informatives — red for unplanned outages, orange for planned ones, blue for general notices, green for new releases — which is the first place to look before escalating a failed delivery.

8. What to do, today

• List the domains your French entity owes, and map each to the person accredited for that collection/déclarant pair. Gaps in that matrix are the most common cause of a missed French deadline.
• Replace any shared-mailbox filing identity with named individuals — at least two per collection, so leave and turnover do not stop a delivery.
• Put certificate expiry dates in the reporting calendar, and remember that renewal requires sending the new base-64 .CER to ONEGATE support.
• Instrument monitoring on the delivery step status, not on receipt of a ticket number.
• Configure the three notification types deliberately, and route late-filing notifications to a monitored group address rather than to one person’s inbox.
• Rehearse in the homologation environment for both weak and strong access before the first production period closes.
• Record the N- prefix convention in the procedure, so a later correction reproduces the original delivery method.

Related: Reporting channels compared across the EU · SURFI — French supervisory reporting · The French reporting calendar for a payment firm · Testing a new return before first submission