FRIDA Rulebook explained: how Europe’s fraud data sharing scheme will work

Payment fraud often crosses institutional borders. A suspicious account identified by one payment service provider may still appear unremarkable to another.

FRIDA — the Fraud Information Distribution Arrangement — is the European Payments Council’s proposed scheme for sharing fraud-related information between payment service providers. It establishes common rules for creating, distributing and updating fraud alerts, helping participants bring external intelligence into their transaction monitoring.

But what will participants actually share? Which information is mandatory? And how do PSPs, Fraud Information Platforms and the FRIDA Central Platform work together?

This guide explains the key concepts in the FRIDA Rulebook version 0.1, reference EPC108-26 published on September 9, 2026.

What is FRIDA?

FRIDA is a framework for exchanging fraud information between Payment Service Providers (PSPs).

Its purpose is to give participants a shared language and distribution mechanism for information about potentially fraudulent activity. A PSP can report a suspicious identifier, such as an IBAN, and other participants can use that information in their own Transaction Monitoring Mechanisms (TMMs).

FRIDA combines three elements:

1. Common rules: who can share information, which data can be exchanged and how alerts are maintained.
2. Standardised fraud alerts: a common structure and fraud taxonomy.
3. A central platform: infrastructure that stores alerts, distributes updates and manages their lifecycle.

FRIDA does not execute payments. It also does not replace a PSP’s fraud detection engine or investigation process.

A FRIDA alert is a risk signal, not an automatic instruction to block an account or payment. The draft explicitly says that shared information must not be the sole basis for customer-facing decisions.

FRIDA timeline: the key dates

The EPC’s published consultation schedule provides the following milestones:

Which payments does FRIDA cover?

FRIDA focuses on account-to-account payment fraud information.

The draft covers transactions processed through EPC payment schemes, including:

1. SEPA Credit Transfer — SCT.
2. SEPA Instant Credit Transfer — SCT Inst.
3. SEPA Direct Debit Core — SDD Core.
4. SEPA Direct Debit Business-to-Business — SDD B2B.
5. One-Leg Out Instant Credit Transfer — OCT Inst.

It also covers relevant account-to-account transactions processed through other schemes within the scope described in the proposed Payment Services Regulation (PSR).

The initial focus is on PSPs in the European Economic Area (EEA). Participation from non-EEA SEPA countries depends on regulatory equivalence, reciprocity and subsequent EPC decisions.

FRIDA should therefore be understood as an account-to-account fraud information sharing scheme, rather than a universal database covering every type of payment fraud.

PSP, FIP and FCP: who does what?

The draft uses a central hub connected to participating institutions through intermediary platforms.

PSPs: the participants responsible for the information

A PSP can perform several roles:

1. Sending PSP: creates an alert and can subsequently update or cancel it.
2. Receiving PSP: receives alerts from other participants and can contribute comments.
3. Account Servicing PSP (ASPSP): it’s the PSP owning the suspicious bank account. The ASPSP should confirm or rejected the fraud alert. It can also enrich account-related information for the suspected account of it’s client.

The same PSP may be both the sender and the account servicer.

FIPs: the connection between PSPs and the central platform

A Fraud Information Platform sends and receives FRIDA information on behalf of participating PSPs. A FIP must meet the scheme’s eligibility (being a CERT, a Central Bank or a National Competent Authority). A PSP may itself apply to act as a FIP, subject to the same requirements.

The FCP: the central distribution hub

The FRIDA Central Platform receives alerts, stores them and makes them available to the connected platforms. The EPC owns the FCP, while an external provider is expected to deliver and operate it.

The working model is: Sending PSP → its FIP → FCP → other FIPs → receiving PSPs

Direct PSP connectivity to the FCP remains a consultation topic.

How does a FRIDA fraud alert work?

1. A PSP identifies suspicious activity and create an alert

A PSP identifies objectively justified grounds for suspecting fraudulent behavior. The alert identifies the relevant subject, such as an IBAN, and includes the mandatory information needed to process it.

2. The FCP distributes the alert

The FIP forwards the alert to the FCP, which makes it available to other connected FIPs. The scheme supports two delivery methods:

1. Push: alerts and updates are forwarded in near real time.
2. Pull: a FIP retrieves alerts and updates periodically.

For participants relying on retrieval, the draft specifies a minimum frequency of once a day and recommends more frequent retrieval.

Near-real-time availability at the central platform therefore does not mean that every PSP necessarily consumes every alert immediately.

3. The ASPSP update the alert regarding its client

The ASPSP can add account information (e.g. Account Holder Name) and its own assessment (confirm or reject the alert).

4. Other PSPs use the information in transaction monitoring

Receiving PSPs can incorporate the alert into their own monitoring and investigation processes. For example, an alert about a beneficiary IBAN may provide additional context when another PSP assesses a payment involving that account.

Which alert fields are mandatory?

For alert creation, dataset DS-01 specifies the following core information:

The fraud taxonomy uses the Euro Banking Association’s EBA Fraud Taxonomy, giving participants a common way to categorise fraud.

Which information is optional?

The draft allows additional information, including:

1. Account holder information: name and address country.
2. Transaction details: amount, currency, references, payer and payee information, and authorisation details.
3. Session data: IP address and device identifiers.
4. Comments: additional structured information about the alert.
5. Digital Services Act notification information: whether a relevant hosting-provider notification was made.

Sending PSPs can choose whether to supply optional attributes. Receiving PSPs receive the full shared dataset but may choose not to integrate optional elements, subject to applicable requirements.

What still needs clarification?

The final legal basis

The draft relies on the PSR compromise text and states that the regulation had not yet been formally adopted and published when the document was prepared. The EPC’s legal review of the rulebook was also unfinished. The final rulebook will need to align with the adopted legislation.

The connectivity and participation models

The EPC is consulting on alternatives to the assumed FIP-based connection model. Sharing alerts about IBANs serviced by non-participating PSPs is also a working assumption under legal review. It should not be presented as a settled capability.

Technical specifications and FIP qualification

Detailed message formats, APIs, error codes, directory requirements and platform documentation require further specification. The EPC is also continuing work on FIP participation requirements and FCP deployment specifications. These details will determine how institutions connect and demonstrate readiness.

Data retention and field consistency

The draft distinguishes between:

1. Alerts available on the FCP for three months after creation.
2. Audit trails and anonymous characteristics retained for five years from the underlying transaction.
3. Participants’ responsibilities for purging their local copies.

What FRIDA means for payment service providers

FRIDA’s value will depend on how effectively PSPs turn shared alerts into useful monitoring inputs.

For institutions preparing for the scheme, the draft already identifies concrete work: mapping mandatory data fields, assessing FIP connectivity, establishing alert ownership and correction processes, and deciding how external alerts will enter transaction monitoring.

The architecture and implementation details are still evolving. But the operating principle is clear: FRIDA gives PSPs a common framework for sharing fraud signals, while each institution remains responsible for interpreting those signals and acting on them.