FNC-RF: How Does the French Fraudulent IBAN Sharing Scheme Work?

With the entry into force of the FNC-RF in May 2026, the fight against payment fraud is entering a new phase. For the first time, Payment Service Providers (PSPs) based in France will have access to a national scheme for sharing fraudulent IBANs, operated by the Banque de France.

Beyond the regulatory framework, one question consistently arises: how does the scheme actually work on a day-to-day basis? Creating an alert, consulting the file, responding to a report—this article provides a detailed overview of the key operational features of the FNC-RF.

A Centralized File, but Decentralized Usage

The FNC-RF is based on a centralized file operated by the Banque de France and made available to PSPs through a secure API. Each institution can:

1. report a suspicious bank account,
2. respond when an IBAN belonging to its institution is reported,
3. regularly consult the list of reported accounts.

A key point to understand: the scheme is not designed for real-time, individual IBAN checks. PSPs must regularly extract the content of the file and rebuild their own local reference database in order to use the data within their internal systems.

Creating an Alert: Reporting a Fraudulent IBAN

When a PSP identifies a bank account involved in fraud, it must create a “MISP event”, which corresponds to a fraud suspicion alert. This declaration follows a strict data model defined by the Banque de France. It notably includes:

1. the IBAN and BIC concerned,
2. the presumed date of the fraud,
3. the type of transaction (SCT, SCT Inst, etc.),
4. the fraud category (CEO fraud, social engineering, etc.).

Optional contextual information may be added (channel used, source of the fraud). This context allows other institutions to better assess the level of risk.

Avoiding Duplicates: Creating a “Sighting” Instead of a New Alert

Before reporting an IBAN, the PSP must check whether it is already present in the file.

1. If the IBAN has already been reported, creating a new alert is not permitted (although no technical blocking exists). The PSP must add a “sighting”, confirming that the account is once again involved in a fraud scenario.
2. If the IBAN has never been reported, a new alert may be created.

This distinction is essential to preserve data quality and prevent an uncontrolled multiplication of redundant alerts.

Updating or Removing an Alert: A Strict Framework

Once an alert has been published, modification options are very limited:

1. only certain contextual fields can be updated,
2. the IBAN, fraud type, and category can no longer be changed.

Direct deletion is not allowed. When a report is no longer justified, the PSP must add a specific removal tag. The effective removal by the Banque de France is not immediate and depends on the central file’s update cycle (overnight batch processing).

Responding to a Report: Account Holder Qualification

When an IBAN belonging to a PSP is reported by another institution, the account-holding PSP must respond. It is required to publish a standardized MISP qualification note indicating the actual status of the account:

1. fraudulent account
2. closed account
3. legitimate account
4. merchant account
5. attribution error

This qualification is critical: it determines how other PSPs interpret the report and how long it remains relevant. Without a response, unjustified suspicion may persist on a legitimate account.

Consulting the FNC-RF File: Regular Extraction Is Essential

Each PSP must implement a regular consultation of the central file via the API. Recommended best practices include:

1. extracting new events and updates,
2. deduplicating data and integrating sightings,
3. updating the internal reference database of suspicious accounts,
4. distributing this information to internal fraud detection engines.

All consultations must be logged and traceable in order to meet audit and supervisory requirements.

A Collaborative Scheme Requiring Operational Discipline

This industry-wide scheme is built on a core principle: collective responsibility. Each PSP acts simultaneously as a contributor, a user, and a guarantor of data quality. Alert creation, duplicate management, timely responses to reports, and maintaining an up-to-date local reference database all directly impact the overall effectiveness of the scheme.

Conclusion

The success of the FNC-RF depends less on the underlying technology than on the ability of banks and fintechs to integrate it properly into their business processes, equip their teams adequately, and maintain a high level of operational discipline.

When properly implemented, the FNC-RF becomes a powerful fraud prevention tool, complementary to existing controls, and a solid foundation for future European developments in fraud data sharing—particularly under the upcoming PSR framework.